[development] What about reviewing patches?
drupal-devel at webchick.net
Wed Aug 13 19:15:30 UTC 2008
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.)...
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
More information about the development