On Fri, 2 Mar 2007, Ian Lance Taylor wrote:
> [ 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.
>
> [...]
> 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
Perhaps a middle ground between what we have now, and "trust but verify",
would be to have a "without objection" rule. I.e. certain people are
authorized to post patches and if no one objects within say two weeks,
then they could then check it in. I think that would help clear up the
backlog while still allowing people to comment *before* the patch goes in.
I think it would be fair to directly CC: relevant maintainers in these
cases so they don't miss the patch by accident.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
