On Wed, Mar 14, 2012 at 02:28:02PM -0700, Russ Allbery wrote: > > According to the constitution we can ask the Technical Committee to make > > such decisions. But we don't have the habit of doing so and I don't > > think the committee would scale if we would start doing so. > > I believe the Technical Committee can do better, but I don't want to say > more than that unless I can actually make it happen, since words are > cheap. :)
Well, this is actually a very important point for this discussion :-) On the paper of the Constitution, the Technical Committee is already all we need to "cover up" for cases where decision by consensus does not work (I'm specifically thinking at §6.1.1 "Deciding on any matter of technical policy" and §6.1.3 "Make a decision when asked to do so" here). But in our practices, we tend to rely on the Technical Committee only for issues that fall in the broad category of "conflicts" (§6.1.2 "Decide [...] where Developers' jurisdictions overlap"). I've the impression that this is partly due to the perceived risk of slowing thing down forever if the Technical Committee fail to answer in $reasonable_time_frame. We're ready to "take the risk" when there is a conflict which seems impossible to solve otherwise, but not otherwise. No matter all the negative aspects of the recent multiarch conflict, I hope people have appreciated that the Technical Committee has been able to decide in a *very* timely manner. And I also understand that, for conflicts, letting things linger might actually be a feature, rather than a bug. But I've the impression there are areas that do not quality as conflicts and that, at the same time, are particularly bad suited for decision by consensus. A specific area I've in mind are distribution wide defaults: what is the default MTA? the default Desktop Environment? editor? web-server? etc. The case of the default init system looks a bit different, but not *that* much. In a lot of default picking scenarios, there is no clearly technical superior solution and at the same time there are a lot of religious battles. That is what make them difficult to be decided upon by consensus. We don't seem to have the right devices to decide on those issue either. Discussion on -devel are not particularly good to give the feeling of consensus for instance, even when the consensus might exist among project members: they're too easy to polarize. Thanks to people like you, we manage to have useful discussions, but I can't help the feeling that there is a disproportion in the energy we put into those discussions and the actual results. If you now allow me to twist a DPL candidate question to a Technical Committee member question :-), do you think default picking topics would be appropriate tech-ctte decisions under §6.1.1/§6.1.3 ? With all the needed disclaimers, of course, e.g.: after substantial discussion elsewhere, assuming the tech-ctte can decide in $reasonable_time_frame, etc. Cheers. -- Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o . Maître de conférences ...... http://upsilon.cc/zack ...... . . o Debian Project Leader ....... @zack on identi.ca ....... o o o « the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature