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

[Federico Mena Quintero <federico ximian com>]

On Thu, 2005-07-21 at 15:18 -0400, Luis Villa wrote:

> [1] worth noting that if Novell is concerned about the stability of
> HEAD, or the violation of promises about quality, Novell is more than
> welcome to participate in the QA team. It would be even more exciting
> if (like Ubuntu, or Red Hat) Novell distributed packages of unstable
> releases to their users. But a quick check last night shows that
> novell/ximian employees are not participating in very actively, filing
> only ~1% of all bugs against the non-evolution core during this
> calendar year; less than either sun or redhat.

Please bear with me along the following rant.

Bugs
----

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...  This kind of work
leaves me little time to play with HEAD and test it.

Examples:  I routinely ask JRB if he knows whether Red Hat has a fix
for a bug I got assigned within Novell.  Glynn saved my ass with some
SMB patches for gnome-vfs.

My ideal bug fix in Bugzilla is like this:  it has an attachment with
the patch; it has a comment with the corresponding ChangeLog entry
that went into CVS.  Then I can grep the ChangeLog out of CVS for the
text in the bug, get the date, look at commits for that date, find all
the files that got changed with that commit, etc.

Mark Shuttleworth, during his keynote at GUADEC, gave an awesome demo
of Ubuntu's meta-bug tracker:  they maintain pointers for the same bug
across the different bug trackers of different distros, and thus they
magically know when any of them manages to fix the bug.  Everyone
would save a lot of time if something like this were a public
resource.

Bugs keep coming in even for old stable versions.  Novell is about to
release a product that works on top of NLD 9 (GNOME 2.6), and we are
finding interesting and hard bugs in there, mainly in gnome-vfs and
Nautilus, that are still present in GNOME 2.10 and HEAD.  If distros
fix these and take the time to propagate the fix to newer versions,
everyone benefits!


Getting fixes for old versions of GNOME
---------------------------------------

Patches for old versions are traded in the black market.  You have
friends in another distro?  You ask them first, "did you guys already
fix this?"  Those patches don't ever manage to reach CVS, where
everyone would be able to get them.

Generic fixes don't get committed to old stable branches in
cvs.gnome.org --- why bother?  People only commit them to the latest
stable branch and to HEAD, if the bug is relevant there.  Other
distros then have to do the same fix-searching actions that I
mentioned above, and everyone wastes time.

Example:  Bill routinely prompts me for a11y-related fixes to
GtkFileChooser in GTK+ 2.4 (paired with GNOME 2.6, from NLD 9); I
point him to the Novell SRPM which has those fixes.

Fixes in newer versions are often hard to backport because many things
have changed.  The fix may be a one-liner in newer versions, but it
also depends on tremendous changes to the underlying infrastructure.

What if we made old stable branches on cvs.gnome.org free-for-all?
Also, what if we encouraged distros to commit their patches directly
to old stable branches?  This would benefit everyone who has to use an
older stable branch; it would also reduce the number of questions to
the poor module maintainers, who don't have time to monitor what
people have done to old versions about which they no longer care.


The "almost-latest" syndrome
----------------------------

GNOME development is going on.  The latest stable tarball for a module
is foomodule-2.8.7.tar.gz; the following branches are maintained:

	foomodule-2-8
	HEAD

At that point, GNOME does its next major release.  Foomodule branches:

	foomodule-2-10
	HEAD

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.


QA
--

Each GNOME version is hard to re-package for distributors.  Old
patches no longer apply; large parts of the infrastructure have
changed, requiring rethinking of the distro's approach to fixing
things.

Distributors can't make their QA teams test things until they finish
the packaging work.

Expect flurry of incoming bugs once QA gets their hands on the
packages:  this is the pattern at Novell and I'm sure other distros as
well.

Lack of automated tests makes for a shitload of duplicated QA work.
Novell is working on LDTP!  This should give us automated tests that
will benefit everyone.


GNOME-wide issues
-----------------

We still allow new APIs to come in undocumented.  How do we expect
upper layers of the platform to use them?  If I were in the release
team, I'd say "no go" for libraries which introduce new APIs without
documentation.  This means both our beloved gtk-doc inline comments
*AND* examples.


  Federico