[development] What about reviewing patches?

[Angela Byron]

Marcel Partap wrote:
> Ryan Cross wrote:
>> Maybe speed of commitments isn't the key problem, but avoiding loosing
>> tester's motivations is something to consider. Or tackle the
>> committers speed if that is the underlying problem. Ideas?
>>
> Mhh.. what about (auto-)committing to a D7.x-next branch after two 
> independent people have confirmed a patch as working? That would give 
> the process of reviewing patches more resoluteness, also liberating the 
> core CVS admins to decide what gets in and what not. Patches that don't 
> proof as a problem in 7.x-next could then be cherry-picked to 7.x-dev... 
> Of course this would make running the next-branch a risky business, but 
> at least it helps getting out of the situation where perfectly good and 
> simple patches are not applied for weeks and months because the 
> concerning code is being completly rewritten on some other issue (module 
> system revamp f.e.)...
> regards_marcel.

Dear sweet Lord, NO! :)

It's imperative that HEAD remain stable at all times, and that automated 
tests continue to pass. There are a lot of seemingly "simple" patches 
that have lots of subtle ways that they break things if you're not 
careful. If we get into the situation where HEAD is broken, development 
effectively stops until things are working again.

It also makes a BIG difference who those two people are. Follow catch's 
advice. Catch is wise. The best shot you have of getting patches that 
you want in core is to become one of those rare patch reviewing ninjas 
like him. Then your voice being one of those two voices may very well be 
enough.

-Angie