[development] Very concerned over Drupal's core development

[Matt Farina]

Some responsibilities, actions, and expectations seem to be unclear to  
me:

Is getting the patches committed the problem or is the problem getting  
them reviewed and to the point where they can be committed the  
problem? Is it getting the from needs review to RTBC?

What is the role of a core committer in the review process compared to  
your average joe developer. Obviously there are differences between  
your average joe developer and a core committer.

I guess I'm trying to find the bottleneck. It doesn't look to be in  
committing the patches when they become RTBC. It seems to be in the  
area of reviewing patches and understanding subsystems and good design  
(especially in the complex parts). Am I missing something?

If this is the case, from a process perspective, adding more core  
committers doesn't solve the problem we are facing.

Or, am I missing something?

On Apr 20, 2009, at 2:24 PM, Nathaniel Catchpole wrote:

> I agree with Earl here. Several of my patches, including quite big
> popular patches that people have bought me beers for, have only got in
> because I'm a stubborn git - either re-rolling them 50 times due to
> patch conflicts or writing reams of arguments to get them committed.
> Not to mention nagging people time after time on irc to get reviews
> and/or advice.
>
> Plenty of other people give up (either on the individual patch or core
> as a whole), and then those patches either sit in the queue for years
> or sometimes get revived by another developer, and then they can still
> sit in the queue for another year or two.
>
> This doesn't mean that /all/ lingering patches are lingering for the
> wrong reasons, but there's a lot of overhead getting patches in other
> than just writing the code.
>
> Having said that, none of this overhead exists for reviewing patches -
> and it's slow review turnover which leads to a lot of the lingering,
> and being someone who reviews a lot of patches is one of the easiest
> ways to get your own patches reviewed faster.
>
>
>
>
> On Mon, Apr 20, 2009 at 7:07 PM, Earl Miles wrote:
>> Dries Buytaert wrote:
>>>
>>> As core matures, we might see more patches getting stale.  I think  
>>> the
>>> reason is (at least) two-fold:
>>>
>>>  1) More patches compete for attention, but fewer of these patches  
>>> are
>>> truly important.  In this case, patches getting stale is not
>>> necessarily a bad thing because history has proven that important
>>> patches will eventually bubble to the top for the right reasons.
>>
>> If the 'right reasons' are because the developers got frustrated  
>> with the
>> process and quit pushing their patch, whereas other developers are  
>> extremely
>> stubborn and managed to push their patch through anyway, then sure.  
>> But just
>> because some developer is bullheaded enough to wade through the  
>> crap doesn't
>> mean that's the right reasons.
>>