Leadership, collaboration and canoncial
Josselin Mouette wrote:
> The problem is that the decisions are always taken for the Ubuntu
> distribution first. 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, regardless of their
> technical merit and relevance for Debian. This way, Debian ends up
> being lead by Canonical, and always lagging behind.
I know i'm going to regret saying this, but someone has to lead the way.
if none of the current Debian developers step up to the task, someone
else has to. This has nothing to do with canonical or ubuntu for that
matter. This applies to all projects and businesses out there.
> 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 would be because the Ubuntu developers are rather afraid of doing a
full scale patch distribution to debian developers due to the fact that
some developers have already declared that they do not want these
patches. This is a huge problem for the ubuntu developers as some people
insist on getting the patches automatically, some don't care either way
and others are angered by people meddling with their packages and don't
want the patches.
My question to you is: what would you do? How would you solve this problem?
The patches are out there, you can fetch them. If you want your patches,
contact ubuntu developers and ask for them. I'm sure they are happy to
give their patches to your packages and embrace your suggestions.
Collaboration is the way, not hostility!
> 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.
I don't thing it is a coincidence! I even think that it is a straight
consequence of ubuntu's influence. But not because they say it should be
kept, it's because they work on it too. They provide patches, do
autocompilation and testing on the packages. That in turn helps the
archs in Debian too. In the proposal there was a clear outline of what
archs should be kept, it's not a coincidence that those archs happen to
be the same popular architechtures that ubuntu ships for.
There is no conspiracy, Debian is not being taken over.
> I'm not saying that for this particular decision, it wasn't the right
> thing to do. 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.
Lately i've failed to see those evaluations, everyone just work for
their own benefit. There are just a handful of groups that work towards
a common goal. GNOME and KDE teams to name some. Others mostly work just
with their own package.
Even though i don't like the Vancouver proposal, i see the issues it
addresses. One of the issues being the fact that Sarge would never be
ready for release if the unmaintained architechtures weren't dropped.
Other issue would be the lack of guidelines. The proposal gives one
guideline: How to get your favourite Architecture supported in a release.
As for the C++ transition, i was given the impression when i first saw
the proposal was that Ubuntu developers asked for the approval of this
proposal from the debian developers. And with a little work, i can find
references to the transition on debian lists that propose the same
scheme that ubuntu is now using, before they began using it.
Personally i feel that Debian Developers should put their jealousy
aside, burry the hatchet and start collaborating with the other
developers out there, not just ubuntu. Besides, you have given your work
out to the public for anyone to use, anyone to modify, anyone to create
derivates from. Why not try and benefit from that symbiosis.
- S
Reply to: