On 7/22/05, Luis Villa <[EMAIL PROTECTED]> wrote: > On 7/22/05, Mark McLoughlin <[EMAIL PROTECTED]> wrote: > > Hi Federico, > > > > On Thu, 2005-07-21 at 22:58 -0500, Federico Mena Quintero wrote: > > > > > I work in the desktop team at Novell, and a large part of my work > > > consists of maintaining NLD 9, which uses GNOME 2.6. When a bug comes > > > in for that version, my life becomes a little hell of trawling old bug > > > reports in bugzilla.gnome.org, correlating them with CVS commits (and > > > Bonsai doesn't work), asking my friends who work for other distros > > > whether they have fixes for the bug already... > > > > I know exactly what you're talking about but ... that's what we get > > paid for. Boo-hoo to us, really :-) > > Speaking as a volunteer ;) it *would* be good for all of us if all you > paid guys got to spend less time on old versions and more time on > HEAD. So anything the community can do to help you do less maintenance > and more devel the community should do, IMHO.
Perhaps an alternative to free-for-all-on-unsupported-versions (which may not be trustable anyway as Mark points out) would be to create a directory where 3rd parties can add patches (along with explanations, pointers to relevant bug reports or whatever, etc.) on old branches? > > That's good risk management. Shipping tarball releases of a > > "free-for-all" stable branch wouldn't be good risk management. > > (1) that assumes stable branches are free-for-alls, which they Well, Federico did suggest it... > shouldn't be (I've always disliked the 'we follow freeze rules until > .0, then .1 is a free for all' approach- seems stupid, since very few Um, it isn't a free for all. From http://live.gnome.org/ReleasePlanning_2fTwoPointEleven: "Hard Code Freeze ends, but other freezes remain in effect for the stable branch." Similar wording has existed on previous release schedules, and it was the policy before we wrote it down there (I added it to the http://www.gnome.org/start/2.7/ page after asking for a clarification on the existing policy just so that it would be clear to others like me who hadn't been developers of modules before). > distros time things right to ship .0). Once we have a testing > framework, it would be easy to limit stable branch checkins to new > translations + bug fixes which have a test case and which have been > shared amongst the distros and the distro QA teams, for example. At Points noted and I definitely agree that the extra testing/vetting would be good. It definitely has its tradeoffs, though, and I feel that making these into requirements might have the effect of abandoning the stable branch altogether and only developing on HEAD. I often just stick bug fixes on HEAD instead of also applying to stable for various reasons (don't want to destabilize the stable branch, it's easier, I don't have to recheck the patch to see if it breaks any freezes). I do apply patches to the stable branch in a number of cases, e.g. when I'm extremely confident in lack of side effects, the bug it fixes is particularly onerous, etc, but time ("laziness"?) and desire ("fun-ness") _always_ enters into the picture and the number of requirements reduce both time and willingness to backport such fixes. Perhaps fewer patches to stable is what you wanted (it does prevent (further) destabilization), but it might result in more work for Federico and other external developers. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list