[ Moving from gcc-patches to gcc ] Chris Lattner <[EMAIL PROTECTED]> writes:
> The LLVM dev policy does not to try to define common sense. It is a > rough guideline which can be deviated from when it makes sense. > > "Trust but verify" starts with trust. What I am about to say is probably an overstatement. And obviously I am not on the steering committee and do not speak for it. There are many significant gcc contributors with a commercial interest in gcc. One thing we have learned over the years is that when there is money at stake, there is a change in the line between "patch is ready" and "patch is a good start which we can fix up later." This applies to me as much as to anybody else; those of us with commercial interests try to wear two hats when discussing gcc, but frankly money has a way of focusing attention. We have also learned is that it is difficult to strip somebody of maintainership status--that is a harsh statement about that person, justified only by egregious actions. In fact, while people have resigned maintainerships, I'm not sure we have ever stripped maintainership from a person. And we have learned that while it is easy to revert a patch because it breaks things, it is difficult to revert a patch because it is ugly or difficult to maintain; complaints in that area are met with disagreement or requests to fix the patch, rather than remove it. A major reason that it is difficult to strip maintainership and difficult to reject an ugly patch is that, for better or for worse, we rejected the benevolent dictatorship development model in the egcs split. And indeed, while this is a controversial statement with which some people will disagree, I believe that that split was caused in part by commercial interests on both sides of the split (and I was there at the time). After the split, we set up a hierarchy of cooperating maintainers. During negotations to end the split, a steering committee appointed itself (I was not much involved in this part, and may be misstating slightly), taking the blessing of the FSF to be its authority. The steering committee explicitly handed technical decisions to the maintainers, with the general understanding that there was no single chief maintainer. Lacking a benevolent dictator means that "trust but verify" does not work, because there is no way to implement the "verify" step. Or, rather: if "verify" fails, there is no useful action to take, except in the most obvious of cases. So my conclusion is that, for gcc, it is wise to require a formal confirmation process before somebody is allowed to approve patches or commit patches without approval from others. Ian
