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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
