Re: Old versions of GNOME [was: Re: gtk 2.8 for gnome 2.12]

[Luis Villa <luis villa gmail com>]

On 7/22/05, Mark McLoughlin <markmc redhat com> 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