Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
Faidon Liambotis <paravoid@debian.org> writes:
> On 08/11/12 01:12, Russ Allbery wrote:
>> There are choices that we don't support because the process of
>> supporting that choice would involve far more work than benefit, and
>> the final goal is excellence, not choice for its own sake. For
>> example, we don't allow users to replace the system C library with a
>> different one. That's something that we *could* do, but the general
>> consensus of the project is that investing our effort in that is not
>> the best way to produce excellence.
> I kind of disagree with that. I don't think that the fact that we don't
> support multiple C libraries is the result of a "consensus decision".
> I think it's just because noone attempted to properly do that and prove
> it's viability and usefulness either to a portion of the userbase or the
> project as a whole.
> Similarly, I don't think the kFreeBSD ports or any of the other Linux
> architecture ports were a consensus decision. People just did it, the
> work was of reasonable standards and useful both to expanding the
> userbase and to improving the quality of the other ports.
I think we're actually agreeing, so let me try to rephrase what I meant to
make that more obvious. :) I think Debian makes a lot of implicit
consensus decisions not to do something simply by no one going and doing
it. And this is particularly true of things like allowing multiple C
libraries that require lots of work by everyone in the project. People
realize how much work it would be up front and never attempt it, which is
a form of consensus decision-making.
It doesn't have to mean that we explicitly discussed it and decided not to
do it. In fact, I find the discussions about things like this to be
mostly useless. They're generally mostly conducted by a small number of
people who are usually bystanders to the actual work, the arguments become
quickly repetitive, and the discussions provide very little substantive
input into whether the work should continue or not.
The real way consensus decision-making tends to happen in the project is
that people try to do something and see how much push-back they get, often
with the help of a few highly-connected people in Debian who are able to
push on making a general change with the various teams. (And we have a
hard time doing things that are project-wide, because that process isn't
very formal.)
For things that someone can go work on by themselves, such as exploring
openrc, the most effective approach seems to be to open a discussion on
debian-devel if they want some input, read the first couple day's worth of
discussion, and then ignore the rest of the thread and just go on and do
whatever one feels the right thing is. Almost none of the subsequent
discussion after the first few days will be original or worth reading, let
alone responding to. Even for things that can't be done by one team,
seeking consensus by talking directly to the other teams and groups most
affected is probably going to be more productive than participating in a
100-message thread in debian-devel.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: