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 »
Attachment:
signature.asc
Description: Digital signature