Rockbox mail archiveSubject: Re: Rockbox development model
Re: Rockbox development model
From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Fri, 10 Aug 2007 08:08:02 +1000
On 10/08/07, DervishD <iaudio_at_dervishd.net> wrote:
> Hi Jonas :)
> * Jonas Häggqvist <rasher_at_rasher.dk> dixit:
> > Development now continues in trunk, and when bugs are found that are present
> > in the stable branch, they should be backported (carefully) and
> > point-releases should be made (perhaps depending on the severity of the bug,
> > either immediately or once a few bugs have been fixed). Only bug fixes go
> > into the release branch - if necessary as work-arounds rather than proper
> > fixes if the fix is too involved and risks introducing new bugs.
While I mostly agree, I dont think a set bug fix period for everyone
should ever be enforced.
The way I see it, is when a new feature goes in which we think is good
enough to create a new stable we branch it. the author of that patch
would then have to fix any bugs which come up in both the trunk and
the new branch (call it testing). only once its agreed that the new
patch is "bug free" do we rename the current stable "stable-at-<date>"
and rename testing to stable.
If a few good features go in around the same time they can all be
branched together into a testing branch and then turned stable when
> The problem with backporting is that from time to time, writing a
> proper backport of some bug fixes will be just impossible. I don't think
> this will be ever happen in rockbox as the internal "framework" (sorry,
> I can't think of a better name) API is stable and small. I mean, this is
> not the linux kernel, where a bugfix in 2.6.x won't be easily backported
> to 2.4.x due to architectural changes.
depends... Its very easy to create a patch which makes working on te
old stable impossible, its not limited to the linux kernel.
Received on 2007-08-10