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

[Elijah Newren <newren gmail com>]

On 7/22/05, Luis Villa <luis villa gmail com> wrote:
> 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.

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.