[development] Very concerned over Drupal's core development

[Angela Byron]

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)).

On a project such as Views, with a very high number,  
$relative_project_quality will be very high. On a project such as any  
of mine ;) with a very low number, code quality will be much lower.  
This is not because I'm a horrible coder or that I'm not conscientious  
about my work or that I don't care about quality. It's because there's  
no body of diverse people chiming in to say "actually that will break  
my use case and here's why," or "I actually find that a bit hard to  
grasp; what if we did it this way instead?" There's no one looking  
over my shoulder for obvious brain-os that I miss in the height of my  
caffeine-powered coding rush. And furthermore, even if I *wanted* to  
bounce ideas off of more experienced developers or peers (which I  
do!), I quite simply can't; they don't have expertise in this space.  
So I do what most contributed module authors do, which is muddle  
through and try my best.

Now, if you do the above query with project = 3060, you will get an  
extremely healthy project. And by having only a small number of  
committers, through whom *all* changes are run, this number holds  
true. However, If we move to a subsystem maintainer committing model,  
we need to change that query for the Drupal project so that it's WHERE  
project_component = %d. And if you do /that/, you do not get a rosy  
Views-esque picture of things like the menu system. You get a very  
worst-case scenario picture of webchick-maintained contributed modules.

So my argument is quite simply that without building this number much  
higher for each of the underlying subsystems, I don't see what choice  
core has *but* to turn into the dark, scary kind of contrib by adding  
more committers to the mix.

-Angie