On Tue, Oct 23 2018, Al Viro wrote: > On Tue, Oct 23, 2018 at 04:28:03PM +1100, NeilBrown wrote: > >> > If that's a clarification, I'm sorry to say that I understand you even >> > less now. >> > What are you proposing? Duopoly? How do you deal with disagreements? >> > Fork? >> > Revert wars? >> >> We already have team-maintainership arrangements - doing the same thing >> at the top level should not be that hard to imagine. >> >> It really about "saying" no. I suspect all members of a team would come >> to much the same decision about any given patch, but they might "say" it >> differently. One might say "anyone who wrote this should be >> lobotomised", and the other might say "I see what you are trying to do, >> but the approach won't work - go look at how we handle XXXX, they have a >> similar problem". Neither will accept the patch, and they will probably >> both accept it after certain changes. But when one of them is having a >> bad day, I would like people to have the explicit opportunity to ignore >> them and talk to the other. Yes, they'll still get "no" twice, but they'll >> also get something approaching sane review least once. > > You still have not answered the question I've asked - what to do in case of > real disagreements, seeing that "pass it to Linus for final decision" > obviously > doesn't work here. And while we are at it, what to do in case when "they" > _agree_ that patch is unsalvagable? I'm quite sure that you can think of > examples of such...
Sorry, things easily get lost in such a wide ranging conversation. Handling of real disagreements is not my problem, unless I am a member of the maintainership team. We have maintainership teams which appear to work, so they provide an existence-proof that something can be achieved. Were I to have an opportunity to be part of a maintainership team, I would probably base any internal agreement necessary on two principles. 1/ People on the team are reasonably competent, and aren't going to commit anything that all controversial without being quite confident. I would choose to trust. 2/ We commit bad patches often, and when we realize, we fix them. You and I have both been on both sides of that. We (the community) even commit quite large mistakes (devfs, control-groups) and the world doesn't end. Accepting imperfection is a key part of Linus' pragmatic approach, and a key part of the success of Linux. If they agree that the patch is unsalvagable, then they say so - politely and with reasons. It is a right-of-review, not a right-of-success. > > BTW, out of curiosity - when has anyone suggested lobotomies[1]? I'd like to > see > details - got to be interesting... Sorry, it was a deliberately ficticious example. Thanks for showing an interest, it is more than a lot of people are doing. NeilBrown > > [1] on kernel development lists, that is - I can think of examples in e.g. > NANAE circa '98 or so regarding the SGI employees responsible for sendmail > setup they used to ship in IRIX, but that was more of a possible explanation > of the reasons rather than suggested remedy...
signature.asc
Description: PGP signature
