[development] Very concerned over Drupal's core development

Earl Miles merlin at logrus.com
Mon Apr 20 19:02:59 UTC 2009

Angela Byron wrote:
> On 20-Apr-09, at 2:20 PM, Earl Miles wrote:
>> Angela Byron wrote:
>>> On 20-Apr-09, at 2:04 PM, Earl Miles wrote:
>>>> Angela Byron wrote:
>>>>> We have this kind of decentralized development model, where one or 
>>>>> two people are solely responsible for code with basically zero peer 
>>>>> review. It's called contrib. And it's notoriously filled with 
>>>>> sub-standard, shoddily documented code that needs to be closely 
>>>>> inspected by individual site maintainers before being deployed on 
>>>>> any serious production sites.
>>>> I stop following your argument here. The only way this argument 
>>>> holds up is that if *all* of contrib is substandard crap. It is not. 
>>>> There is a level of contrib that is above that, and there is a 
>>>> reason those particular pieces of contrib are above that. Chew on that.
>>> And this level contrib is the kind that has enough users so that peer 
>>> reviews occur naturally, or at the very least peer QA after the fact. 
>>> As we've noted, peer review and peer QA is *not* happening with these 
>>> core subsystems, which makes it a lot closer to the "darker, scarier" 
>>> contrib. So I'm not sure what there is to chew on. :)
>> Perhaps you attribute more peer review and QA to some of these modules 
>> than is truly there. I don't think there is very much. There is peer 
>> review pretty much after the fact; that's the review that said "it's 
>> ok to use this module."
>> But the responsibility of the committer is what made that happen in 
>> the first place. I personally believe that anyone who is given the 
>> right to commit directly to Drupal core is going to think several 
>> times longer before committing something than he or she would to 
>> contrib. Obviously this varies based on personality, but the 
>> suggestion that adding more committers to core will turn core into 
>> contrib does not work for me.
> I guess I view it as the following simple pseudo-query, assuming an 
> active maintainer:
> $relative_project_quality = db_result(db_query('SELECT (number of active 
> participants in issues, filtering out '+1 subscribe') FROM 
> {the_issue_queue} WHERE project = %d', $project->nid)).

What if a project is small and so mature that there simply aren't 
issues? Does that make it poor quality? This metric does.

Also, flexinode. That also would hit your metric, but the code quality 
of flexinode was not high. It had a huge number of issue participants 
because it was a cool idea, not good code.

In fact, what your metric gets you are "Things people really want but 
may not work right," not "quality contrib modules."

More information about the development mailing list