Jonathan Gordon wrote:
> 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.

I don't follow your reasoning here. Especially in combination with the part
you quoted. I'm not suggesting enforcing a set bug fix period. I'm
suggesting a period after branching in which people are encouraged to work
on bugfixing the upcoming release - the trunk branch is still open during
this time if you have a feature you simply must commit (and it'd actually be
a good idea to commit features that need loads of testing at this point in
time because it's the point farthest from release).

After the release is done, it enters maintenance mode, during which work
continues on trunk (it was probably never completely stopped, but the period
of bugfixing is ended), and any bugfixes are backported if applicable.

Consider this illustration (if any blind readers are reading, I apologize
for my lack of eloquence to describe this without resorting to ascii graphs):

                111111111122222222223
       123456789012345678901234567890
Trunk ---.-----------------.---------
          | |
rel-3.0 '--+----+----+---+|
rel-3.1 '--+---

The numbers above the line are imaginary time-units (from 1 to 30) I will
use in the following:

4. We decide that we have a relatively stable trunk, and branch for 3.0 release.
4-6. Everyone is encouraged to fix bugs in the rel-3.0 branch.
7. Rockbox 3.0 is released. After this (or possibly during 4-6), new
features should get into trunk, to make sure they get the maximum amount of
testing while in trunk,, before the next release is branched.
7-21. Bugfixes are backported to the re-3.0 branch.
12,17,21. Rockbox 3.0.n is released, containing these bugfixes.
22. The old branch has become unmaintainable, or the features merged have
matured, and rel-3.1 is branched. rel-3.0 can in theory remain open and be
updated if there's a good reason for it. The cycle starts over.

Again, the release branches receive ONLY bugfixes. If fixing a bug is likely
to introduce more bugs, the bug should simply be documented as known for
this release. It should of course be attempted to fix in trunk, and will be
an argument for creating a new release branch sooner rather than later,
depending on the severity of the bug.

As I see it, the time between branching and releasing shouldn't be more than
2-4 weeks - longer than that, and the devs are probably stuck anyway.
Release with known bugs documented, and continue working on trunk. The time
between branches (and thus releases) should probably not be terribly long
either. Somewhere between 3-6 months seems reasonable to me.

The previous attempt at feature/bug driven releases ("we want these features
/bugs done, and then we'll release") were quite clearly failures. I'm
thinking that it was quite possibly because of this thinking that they
failed. While some people were indeed working towards these goals, it was
impossible to reach a point where they were met, and no further instability
was added.

> 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
> its ready.

I think this would create unnecessarily many branches, and
questions/discussions of when to branch, and put an unreasonable burden on
the specific patch author. In reality though, I don't think it's a lot
different from what I proposed, but I humbly think that my way of handling
it is a lot clearer in its intent, and creates less confusion.

>> 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.

If trunk has diverged so much from stable, that it's impossible to fix a bug
in the stable branch, you do two things:

First, can a workaround be created to at least hide the bug in some way on
the stable branch? If so, do that. In any case, document the bug and workaround.

Secondly, how severe is the bug? If it's a very important bug, the next
release should preferably as soon as possible, rather than waiting for more
features to go in. For less important bugs, simply documenting it in some
"About the current stable release" page somewhere should suffice.

-- 
Jonas Häggqvist
rasher(at)rasher(dot)dk