Thorsten, On Mon, Oct 28, 2013 at 05:23:33PM +0000, Thorsten Glaser wrote: > Lucas Nussbaum <leader <at> debian.org> writes:
> > I think that it would be a failure of the Debian project if we had to > > have a GR about such a technical decision. I think that we need to > > trust that the Technical Committee will make the right decision. A GR > > about this will likely result in splitting and hurting the project even > > more. > In my perception, it’s the other way round: a CTTE decision will be > seen as dictated from a small group, and the possible conflict of > interest has been raised, no matter whether it indeed matters in > the CTTE decision or not, people are saying it’s fishy. There is a lot of indirection in your message here: "will be seen", "some people". You don't say that *you* mistrust the Technical Committee's decision on this issue. If you do, please come out and say so directly. As it stands, I don't find your argument here very compelling at all. Yes, there will be some people who criticize the TC decision as being that of a small cabal; but how many of the people levelling that criticism are actually Debian deveolpers? I don't think you were around in the years immediately after the constitutional bugfixing that enabled Debian to start having GRs again after a long hiatus, but I was. The experience of that time convinced me more than anything else that direct democracy is a very poor system of government for an organization of any size, because it wastes a lot of people's time and causes a lot of anguish over issues that at the end of the day are not very important. GRs on controversial subjects are not healthy for the project, and we should not go out of our way to pull the trigger on GRs if we don't have to. The decisions of the Technical Committee are always subject to review by the developers at large via the GR process. If a sufficient number of developers disagree sufficiently strongly with the decision of the Technical Committee that they wish to raise a GR, it is always their prerogative to do so. But even if this happens, it is a much better process for Debian as a whole to let the TC do its work first, evolve the pro/con arguments in a small group, and then present their conclusion to the project rather than to have all developers immediately pile on and tackle the question directly from scratch. In the common case, everyone is reasonably happy with the TC's conclusion and there's no further need to spend time on a controversial project-wide discussion. In the exceptional case, some group of developers disagree strongly enough with the outcome, and think the majority may support them, that they will submit a GR to overturn the decision - but in that case they have specific technical discussions from the TC that they can refer to instead of having to start the discussion from scratch. Either way, it's much less of a time sink for Debian developers as a whole to let the TC do the hard work first while the rest of the project can continue being productive elsewhere. > (Also, do remember that any decisive outcome other than “support > multiple ones including systemd” and “systemd-only” will need to > lead to the removal of GNOME from Debian. Absolutely not true. As Tollef mentions in his follow-up, one of the options is to fork logind and maintain it. This is not an improbable outcome. Logind is a good interface, and there's a lot of value in continuing to use it, regardless of what init system we choose. If Debian chooses to ship upstart as the default, I will almost certainly be inteested in making sure that logind continues to be well-supported on top of upstart, in both Debian and Ubuntu. The work to do this on Ubuntu has so far been straightforward; while there are some technical hurdles in the future for making logind continue to work on non-systemd systems, these are known issues and not at all insurmountable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
