Re: Better collaboration with distributions [Debian response 1]

[Frederic Muller <fredm gnome org>]

Heya,

Le mercredi 05 janvier 2011 à 22:55 +0800, Frederic Muller a écrit :
> > As introduced by Stefano I am contacting you on behalf of the GNOME
> > community in order to get some initial feedback on an improved
> > collaboration effort between GNOME and the downstream projects 
making us
> > available.
Thanks for making this effort, it is much appreciated. I have the
feeling that, on our side, we are not doing enough in terms of upstream
collaboration today - mostly as a result of a lack of resources - and
efforts from other sides are really welcome.

(Note that everything on this mail is my personal view, and maybe Emilio
will add some things I might have forgotten.)

> > As GNOME contributor base is slowly but surely growing we have been
> > thinking of allocating some resources on this topic. Our initial
> > objectives are to find out what we could be doing to simplify and ease
> > your work related to GNOME integration in general and some specific
> > issues such as better communication, help with accepting patches and
> > sharing information between distributions on those issues. We already
> > have a mailing list but little is happening there, so we must be 
missing
> > out on something.
I am among those who follow this list, and I really appreciate the
announcements that are made there, although I find them to be
insufficient in number. In the lenny timeframe, most of them have been
followed by a stable update on our side.

> > Some of the initial information we'd like to gather are related to long
> > term support of specific GNOME releases:
> > 1. What version(s) of GNOME do you maintain in a stable fashion?
Debian lenny features a mixture of GNOME 2.20 and 2.22 ; mostly 2.22,
excluding anything linked to gvfs (nautilus, panel…)

Debian squeeze will feature GNOME 2.30 with a few bits of 2.32, mostly
some bugfix releases, excluding anything related to gsettings.

> > 2. How much work does this represent?
We generally spend a lot of time stabilizing the releases in times of
freeze. Debian has long freeze times and we use them to polish the
stable releases a lot, trying to integrate as many bugfixes as possible
and to improve integration of the various GNOME and non-GNOME
components. This process takes a lot of time during freezes - times at
which we are bad at integrating the latest upstream trends.
Comparatively, it takes very small time once released. The stable update
policy is very strict, so in stable releases we only fix security bugs
or bugs with a strong usability impact. That makes about one upload
every 1-2 months.

> > 3. Do you feel there is duplication of work between what you do and 
what
> > other distribution do?
Yes, certainly. Not much in terms of long-term maintenance, but this
definitely happens at times of stabilizing a given GNOME release. With
each of them comes a number of modules that are not as polished as
others, and we spend a lot of time putting band-aid. For example, in
GNOME 2.30 we spent a lot (really a lot) of time putting gdm into shape.
We tried to collaborate with other distros on that matter, but in the
end it was just about sharing patches on bugzilla, not about stabilizing
the 2.30 release as a whole, given that each distributor had its own
priorities. Other issues included epiphany/webkit (which we are almost
the only ones to ship by default), and being able to run GNOME without
PulseAudio (for which we share patches with Gentoo).

That said, and on a side note, GNOME 2.30 was definitely, overall, the
best release I had to deal with. I recall GNOME 2.14 (that we used for
etch) being a nice one too.

> > 4. How do you see a potential collaboration between all of "us"
> > (upstream and downstream projects)?
My #1 priority would be a better ability to share changes applied to
stable branches. That means two axes of improvement:
     1. More long-term maintenance of modules. Currently it stops after
        6 months at the next release, and we would gain a lot with more
        bugfix releases later.
     2. Faster transfer rates between downstream patches and upstream
        commits, to avoid discrepancies between distributions and
        mistakes in patches themselves. On this matter, there is margin
        for improvement on both upstream and downstream sides.

> > 5. We are definitely aware that today each of us use a different bug
> > tracking system. Do you see any possible technical solution that could
> > address this specific issue?
I don’t think we can, overnight, get everyone use a compatible system.
This would mostly result in Ubuntu trying to sell Launchpad to
everyone :)
In Debian we have a few features that make upstream bug tracking
easier.
      * A script named bts-link updates statuses of Debian bugs
        according to the status of upstream bugs to which they are
        forwarded. We can get easy links to upstream this way; what is
        missing is the ability to link them back from Bugzilla. BZ now
        supposedly accepts links in bug reports, but refuses the ones to
        bugs.debian.org; maybe it’s just a matter of configuration.
      * patch-tracker.debian.org which easily lists all patches we apply
        to a given package in a given release. Unfortunately only a few
        upstream maintainers look there - but it’s also understandable
        since that would be a lot of work to do that for each
        distribution.
      * The package tracking system (packages.qa.debian.org) allows to
        subscribe to bug reports or new releases for a given package.
        For example this is used by the upstream totem maintainer, and
        we get an unmatched responsiveness for bug fixes in this
        package.

> > There are probably more things to be discussed, but before continuing
> > the discussion among the GNOME people we believe it would be great to
> > gather some initial responses and see what you would be expecting or
> > needing from the GNOME project. Should there be any extra comments you
> > feel are important to convey please do feel free to let us know.
The overall comment I’d like to make about GNOME releases from the
distributor point of view is that not all releases are suitable for a
stable distribution. For example, GNOME 2.32 with its mixture of
GSettings and GConf, and the mess with introspection support, is clearly
not. Whether the currently available GNOME release is good enough for
our stable release is mostly a matter of luck; sometimes we just do as
we can, and it’s not always enough.

In all cases, thanks again for your interest.

Cheers,