Faidon Liambotis <parav...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zk62uriw....@windlord.stanford.edu
