[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames


Josselin Mouette [2005-06-05 18:50 +0200]:
> The problem is that the decisions are always taken for the Ubuntu
> distribution first.

I can't remember any situation where somebody said "Don't do this in
Debian yet, Ubuntu wants it first".

I don't see any world/Debian domination plan here. Just right now it
is much easier to do major changes in Ubuntu than in Debian, since
Debian is close to a release, and Ubuntu is still quite early in the
release cycle. But in a few weeks (hopefully), Debian can develop at
full pace again.

> Then, people from Canonical or people wanting to keep compatibility
> between the two distributions will always want Debian to follow the
> decisions taken for Ubuntu

Of course that is always a goal, that's why major changes should
usually be coordinated with Ubuntu before the change takes place (this
had happened for the C++ transition). 

> , regardless of their technical merit and relevance for Debian. This
> way, Debian ends up being lead by Canonical, and always lagging
> behind.

If you mean this in a general sense, what is an example of this? If
you mean the C++ transition in particular, do you think that it is
_not_ relevant to Debian? The people that are responsible for it in
Ubuntu are the same that maintain the relevant packages in Debian, so
they really should know what they are doing. 

At the same time you both complain about Debian lagging behind because
of Ubuntu, and Debian being pushed forward by Ubuntu.

> Actually, you can just look at what happens and see this is already
> the case. Many packages in Debian are lagging behind Ubuntu, and
> Ubuntu-specific patches are not forwarded to Debian maintainers,
> regardless of the declarations. 

This statement is just wrong. Many patches are forwarded to the BTS
and collected at patches.ubuntu.com. And even those that are not
forwarded explicitly are always available at
http://people.ubuntu.com/~scott/patches/. I'm sure that as soon as any
Debian maintainer asks for clarification about the (rather coarse)
files in this archive will get a satisfying explanation.

> You can also see that the only architectures supposed not to be
> dropped from testing in the Vancouver proposal are the architectures
> Ubuntu supports. Is it a coincidence? I'd like to think so.

Of course, Ubuntu picked some architectures completely arbitrarily. It
was a really great piece of luck that these arches happened to be the
most prominent in the world out there.

> I'm not saying that for this particular decision, it wasn't the right
> thing to do. 

Ok, that answers above question.

> I'm questioning the independence of the project as a whole
> for important technical decisions. Debian has always been superior
> because we used to take the time to evaluate solutions and keep the best
> one, technically speaking. If we merely follow Ubuntu, decisions won't
> be only based on technical merits, but also on political and economical
> ones.

Who said that we have to follow Ubuntu all the time?

I completely agree. In particular there are things in Ubuntu that
don't fit into the concept of Debian (examples: the set of standard
installation packages, the "zero debconf questions" policy, not
supporting more architectures, and so on). But OTOH there are many
good things in Ubuntu which would fit very well into Debian (proactive
security enhancements, better hardware support, and whatever). Why do
you think adopting them in Debian would be bad in any way? As long as
this remains an offering, I think Debian can benefit from that. And at
no time Ubuntu will be able to force decisions into Debian.

Have a nice day,


Martin Pitt              http://www.piware.de
Ubuntu Developer   http://www.ubuntulinux.org
Debian Developer        http://www.debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: