Re: Better collaboration with distributions [Debian response 2]

[Frederic Muller <fredm gnome org>]

Hi,

I agree with most of what Joss said. I'll just add a few comments.

On 05/01/11 15:44, Josselin Mouette wrote:
> > 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.
I guess this is the distributor-list list.

>> >> 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.
Not sure what you mean here Joss. Of course during freezes we don't 
integrate
the latest and greatest of new GNOME (sometimes development) releases 
for the
next stable release, since it's a freeze. :)  Or do you mean in e.g.
experimental for the next release?

> > 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.
I'm not sure this would be of a lot of benefit, since for many/some distros,
once they are released, they hardly include new upstream releases (that 
includes
us and Ubuntu, for example). They cherry-pick selected critical patches 
instead.
So 2 years of point releases wouldn't be that useful I think.

> >      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.
Right. IMHO it's not the upstream maintainers who should be looking at 
patches
in downstream packages, but we should forward them. In this regard we've
improved a lot in the last months.

> >       * 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.
IMHO GNOME 2.32 was a mistake. GNOME 3 was due by then, but it was 
delayed and
instead GNOME 2.32 was released, and it had a big fix of stuff as you 
point out.
It would have been better to not release nothing at all, maybe a GNOME 
2.30.4,
although that could have been bad for distros and other people that were
expecting a major release.

Cheers,
Emilio