|
Rockbox mail archiveSubject: Re: Rockbox development modelRe: Rockbox development model
From: Jonas Häggqvist <rasher_at_rasher.dk>
Date: Fri, 10 Aug 2007 02:50:11 +0200 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)dkReceived on 2007-08-10 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |