[development] Subsystem maintainers or targeted committers?
rob at robshouse.net
Mon Jul 2 09:24:08 UTC 2007
The link 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.
More information about the development