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. > > No one ever does a last tarball for foomodule-2.8.8. Thus, the "last" > > fixes in the foomodule-2-8 branch are effectively lost, since > > distributors can only package the latest tarball. > > > > All distros have packages with a "update-to-latest-in-branch.diff" > > patch. If that last tarball existed, distros would save a lot of > > time. > > I don't think tarballs releases from old stable branches would help - > much, anyway. From my experience in both Sun and Red Hat, you generally > only want to include (in updates to your stable, supported product) > fixes for bugs which are serious, reported by a customer and don't > introduce significant risk of de-stabilising the product. > > 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 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 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 the very least, a list where all these things were collaboratively discussed/tested before commit to mainline would give everyone one repository to look at if they couldn't take mainline directly. (2) Obviously the distros want to include an incredibly minimal set of patches in their maintenance releases. But those releases also lag anywhere between months and years behind HEAD. Better collaborative 'enterprise' management of the stable branch after .1/.2 but *before* the enterprise releases would help everyone quite a bit, I think, and not jeopardize anyone's post-release patch management strategy. Sort of rambling without a coherent theme- Luis _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
