On Mon, Oct 18, 2010 at 12:33:28AM +1100, Jonathan Gordon wrote:
> Arguably our release system is broken. I say this because too often
> when someone reports a bug the first response is "try the svn build"
> which basically means we don't have much trust in the releases (or we
> dont release often enough.)
"Try the svn build" is an appropriate response if it's been established
that the reporter is indeed seeing a bug. I do get the impression though
that people start giving that response before even understanding what the
actual problem is.
This is definitely a problem, and it's been bugging me for a while. I
suspect the problem is actually even worse, I'm pretty sure we have a
lot of users who won't come and ask for help, they just either live with
the problem, go back to an older release, or decide that rockbox is too
buggy to be usable. We're hurting our popularity here.
> So, I've thought about another possible system we could try and see if
> it works any better.
> At each release we would branch (like today) but instead of that
> branch being pretty much locked, we/someone would port (where it is
> possible/makes sense) *bug fixes* back into that branch. Then a new
> point release would happen every 2 or 3 weeks. Now instead of
> releasing a new branch/stable tree every 3/4 months we would do one
> when something "big" happens, subject to some sort of consensus.
This sounds like a good idea. Let's try to do it.
> Ideally we would never create a new stable with more known bugs than
> the previous.
> This would have a few benefits:
> 1) people wanting slower moving development branches, but still
> wanting bug fixes would have this.
> 2) for bugs which are feasible, there would be at most 3 week lag
> between it being committed and it going into a stable build for users.
> This means we would first ask users (if they are using the stable
> branch) to use the latest stable first, and only then ask them to try
> the svn build (or maybe even nightly/svn from stable)
> The downside of course is more work, and it needs a good bunch of devs
> actually using the release and the dev branches to make sure neither
> This idea is obviously not complete so any suggestions would be useful
> (and some sort of yes/no to see if this is something we want to at
> least try).
> Some questions:
> How would we decide which bug fixes go through,
Obviously anything we'd consider to be a release blocker. Crash bugs,
important playback issues, that sort of thing
Apart from those I suspect it will depend on how involved the fix is.
I think this is a place where Daniel's proposal of a few weeks ago could
work well: two or three people in favour, nobody against.
> and who would do the work?
Anyone who volunteers, as usual :)
> I believe AlexP suggested waiting a few days after a bugfix
> before porting it to make sure it doesnt cause more problems that it
This will depend on the code I think. I don't think we need a general
> Who would do the work? Having a fortnightly cron job to do the builds
> would be the best, with some way to tell it to hold off a run.
Maybe. I'm not sure if I'd want this to be fully automated. At most
possibly an autobuilder with an automated way of asking the release
manager to approve the build? I wouldn't want a buggy release because
the release manager was on holiday and couldn't stop it.
I think we'd definitely want dailies or autobuild on commit though. If
the branch isn't tested, it won't work.
> Would language updates go through?
I see no real reason not to, provided all other conditions are
> Lastly, http://www.rockbox.org/irc/log-20101012#10:18:53 is the IRC log.
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
Received on 2010-10-18