Re: Debian decides to adopt time-based release freezes
On Wed, Aug 05, 2009 at 09:04:46AM +0100, Steve Langasek wrote:
> I'm not sure whether this subthread is really going anywhere, given that it
> seems to have devolved into a complaint about the handling of a particular
> bug, and playing whack-a-mole on a public mailing list in response to
> individual interactions seems a thoroughly ineffective way to change
> anything about the Debian-Ubuntu relationship at large. Still, given that I
> have personal knowledge of the bug in question, I can't help but respond...
The bug is actually not a single bug but reflects the cooperation
between Ubuntu and Debian on the eglibc side. It may be different in
some other areas, but it reflect my daily feelings.
> On Tue, Aug 04, 2009 at 11:18:26PM +0200, Pierre Habouzit wrote:
> > On Tue, Aug 04, 2009 at 10:29:11AM +0100, Steve Langasek wrote:
> > > I'm sorry that you have a negative impression of Ubuntu's relationship
> > > with Debian, but there's plenty of data available that contradicts
> > > your conclusion (including BTS reports that have been posted to this
> > > very thread).
>
> > The problem is there is also plenty of data, like for example the recent
> > #539950 (on a package never uploaded to Debian) which is looking a _lot_
> > like LP#408901. In this bug, the Ubuntu developer is (IMHO) trying to
> > make the Debian one find, fix and patch the bug for him.
>
> The package has not yet been uploaded to Debian, but the package that was
> uploaded to Ubuntu is based on the Debian repo where eglibc 2.10 is being
> staged for upload. Why do you conclude that the Ubuntu developer is trying
> to make Debian find and fix the bug? Do you think that Ubuntu developers
> should only communicate with Debian about bugs they already know the fixes
> for, and that anything else implies that Ubuntu is expecting Debian to fix
> the bug for them? Is sharing information about known bugs not *also* a
> useful form of collaboration?
>
> Do you think Ubuntu developers should not communicate with Debian developers
> about possible upcoming regressions? Or are you only arguing that such
> communication should not take place in the BTS? (I can certainly sympathize
> with the latter, since using non-existent version numbers when filing bugs
> in the BTS is effectively garbage data; I'm just not clear exactly what your
> objection is in this case.)
>
> Given that this is almost certainly an upstream bug, and a regression vs.
> 2.9, I would think that the Debian maintainers would, in the general case,
> welcome being kept in the loop about such a bug. If that's not true, how
> should the Ubuntu developers know this? In this instance, the bug was
> forwarded to Debian by a developer who does a significant proportion of the
> glibc work in Ubuntu, and is not an unknown entity to the Debian glibc
> maintainers. If the Debian glibc maintainers don't want to receive warning
> about such upcoming issues, or want to receive it by other means, has any
> effort been made to communicate this to Matthias? (Posting to
> debian-project certainly doesn't count...) How in the general case is
> Ubuntu developer X supposed to know whether Debian maintainer Y is going to
> welcome being kept apprised of upcoming problems they will face when
> upgrading to a new upstream version, or will instead regard it as a "dirty
> trick"?
In an ideal world seeing such a bug report in the Debian BTS would have
been appreciated. In practice, except a few minor exceptions, the code
always flows from Debian to Ubuntu, so I clearly have some a priori.
I have been personally informed about this bug about 15 minutes after it
has been submitted in the Ubuntu BTS, thanks to IRC. I usually get
informed about problems on the Ubuntu side that way, and until recently
I answered or fixed them depending on my *free time*.
In short Ubuntu is doing cosmetic tweaks to the packaging, and Debian is
maintaining the packaging, writing patches, and does most of the
interaction with upstream. Add to that Debian is currently lacking
manpower to follow the rate of the bug reports.
With all those reasons, seeing a bug report from Ubuntu without much
analysis than in the original bug report really makes me think Ubuntu
wants to see the bug fixed by Debian.
I am pretty fine cooperating with Ubuntu, provided that Ubuntu adds some
manpower to do part of the job.
> > The problem is (as a DD) that I would expect Ubuntu to collaborate the
> > most on the harder core packages, meaning the toolchain, the kernel,
> > X... Alas, it happens more coincidentally than on a regular basis, and
> > that saddens me.
>
> With the exception of the kernel, where the packaging is more or less a
> complete fork between Debian and Ubuntu, I think all of these components are
> areas where Ubuntu developers collaborate. Many of the packages are often
> in sync between Debian and Ubuntu (with experimental if not with unstable),
> changes originating with Ubuntu are frequently made available in both Debian
> and Ubuntu simultaneously when feasible, and when not, the changes are still
> (IME) published to Debian ASAP when they make sense in a Debian context.
Yes, the eglibc package in Debian and Ubuntu are very close, simply
because Ubuntu does not do real changes (or bad changes that we don't
want to see, like ignoring the testsuite failures without understanding
the problem), so there is almost nothing back to contribute...
People are often complaining that Ubuntu doesn't give back their patches
to Debian, they are wrong as the reason is that often such patches do not
really exists.
> Now perhaps what you mean isn't that you expect Ubuntu to collaborate
> better, but that you expect Ubuntu /to do more of the work/. That's a
> different question, and not one that can be solved at the level of
> individual developers - the Ubuntu developer community is much smaller than
> the Debian developer community, and if the work output from Ubuntu doesn't
> meet your expectations, it's not because Ubuntu developers are sitting idle
> waiting for Debian to do all the work.
You are touching the problem here. You've also told me on IRC that
Matthias Klose does not have a lot of time to work on the glibc side.
That's were the business model of Canonical fails (to be friendly in the
Open Source community, to makes money it probably works well). Canonical
put a lot of manpower and money on the Gnome project as it is what the
end user sees, but forgets that a GNU/Linux distribution is also made,
among other things, of a Linux kernel and a libc. It won't work without
those essential components.
The Free Software is not about taking the work from others, it is also
about sharing part of the work. If you look a bit, the contribution
of Ubuntu on the (E)GLIBC packaging represents very few, and if you look
at the upstream side it's even less. Debian or Gentoo separately
contributes a lot more than Ubuntu.
If Ubuntu does not want to share part of the work, it's a choice, but
then don't be surprise that Debian doesn't want to contribute.
I also don't buy the argument "upstream being uncooperative" as an
explanation for the number of contributions. This surely doesn't help,
but it does not prevent to submit bugs or patches. Even if the patch is
ignore or rejected, other people are looking at the bug tracker and the
mailing lists, and will re-use them, exactly like Debian re-use patches
like that posted by other distributions. Also you now also have the
option to re-submit it to EGLIBC. Sometimes the patches are rewritten
and the attributions lost in the meanwhile, but as the lists are public,
this does not prevent other persons following them to recognize your
work.
That said I really appreciate the effort put by Ubuntu on working on
multiarch with Debian. This is an example that contribution can work
well when both side play the game. Unfortunately that does not seems to
be the case on all domains.
Cheers,
Aurelien
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: