[development] Subsystem maintainers or targeted committers?

[Robert Douglass]

The link[1] Thomas Barregren posted was quite interesting. Indeed, 
Drupal seems to be experiencing some of the issues the Linux kernel 
faced some years ago, albeit not nearly as drastically. Reading through 
that post and the rest of the comments on the mailing list here bring me 
to some observations.

1. Gabor has done a great job. In particular, he has led the drive for 
i18n features in core. That's awesome.
2. Gabor came in almost as if he had a mandate to focus on #1, and 
indeed, he has focused nearly exclusively on #1.
3. Whether this was by accident or design, it worked well and would seem 
to be scalable and repeatable.
4. Dries could "scale" his vision of Drupal architecture by assigning 
more such targeted committers. He could say "Jeff Eaton... for D7, your 
job is to make sure the Data API gets in, and that it rocks." Or 
"KarenS, for D7, your job is to make sure CCK hits core, and that it 
rocks." Or "Earl Miles, get your query builder into core and integrated 
at a deep level, and make sure it rocks."
5. Whether or not the people in #4 get core commit privileges is nearly 
irrelevant (though I'd opt for them having commit privs, with the 
understanding that they were to be exercised on a limited domain of 
applicability only.) The important part would be that one person was 
understood to be "in charge" of the features. Any other developers 
wishing to see those features into core would have to work with the 
target committer, and the target committer would be responsible for 
tracking and coordinating the effort.

We do this in a way now, so codifying it would only be a reinforcement 
of current patterns. Yet by making it formal we'd be enhancing the 
efficiency and scale of the operation. Such an approach may be the way 
in which we get high quality features into core while Dries maintains 
the overview and flexibility to do what he's been doing so well.

-Robert


[1] http://lkml.org/lkml/2002/1/28/83