[development] Time to take away RTBC from every Joe
walkah at walkah.net
Thu Feb 21 19:01:31 UTC 2008
Uh oh, angie... ;-)
On 21-Feb-08, at 1:37 PM, Angela Byron wrote:
> James Walker wrote:
>> On 21-Feb-08, at 7:57 AM, Moshe Weitzman wrote:
>>> FYI, what Karoly proposes is exactly how the Mozilla project works.
>>> Each patch needs a "super review" from a fixed (but large) list of
>>> reveiwers. See http://www.mozilla.org/hacking/
>> Those who have bothered to stick around and listen long enough
>> while I ramble will know that I'm actually in favor of this kind
>> of approach. I think it has several benefits :
>> * Clear responsibility - in case of questions, complications, etc
>> - the "buck stops" at a defined point for resolution.
>> * Allows for "domain experts" - very frequently patches come in
>> that can have tricky, subtle implications for some of the more
>> complicated systems (menu, formapi, search etc etc etc) and it's
>> *really* hard (frankly too much to ask) for the few core
>> committers to have comprehensive understanding of all of Drupal at
>> this level.
> But we already have this, albeit more informally:
> - OpenID patches don't get committed until you've looked them over.
> - Actions patches don't get committed until John VanDyk has chimed in.
> - chx or pwolanin need to look at menu system patches.
> - Jeff Eaton or chx need to approve FAPI patches.
> - Barry or Frando need to thumbs-up Schema API changes.
> - merlinofchaos and dvessel are in charge of theming-related changes.
> - quicksketch is the Drupal JS master.
> And so on. MAINTAINERS.txt /already/ means something.
Well.... *sorta*. If we're using me as an example, yes, it's been
mostly true for OpenID so far - definitely not true for blogapi ...
it's been broken several times over the years by patches I missed on
their way in.
Perhaps I'm a bad maintainer (most would argue I am), but I think we
could do a lot to help maintainers out.
> The vast majority of patches, however, are not directly related to
> these types of low-level changes that require specific domain
> knowledge; they're string fixes, or usability improvements, or
> logic fixes, or simple new features, and so on. Being able to rely
> the "wisdom of crowds" in the larger community to handle tasks like
> reviewing patches and changing issue statuses is a /good/ thing.
To a point. Never would I suggest we remove the wisdom of the
crowds... everyone should be encouraged to submit and review patches.
Currently, however, we have a very narrow gate (Gabor and Dries for
D6) for stuff that actually goes in. What I'm suggesting (or
envisioning) is actually widening that gate a bit - by expanding to a
super-review tier (that includes MAINTAINERS.txt - and likely
others) ... to help ease the burden of the core committers in
verifying that an RTBC is *really* RTBC.
> Further, I think Mozilla's model works because of the Mozilla
> Foundation, and the Mozilla Corporation. MoFo directly gets
> involved in setting directions and policies of development and MoCo
> has employees who are paid to oversee certain aspects of the code
Yes, Mozilla's model is different - based on MoFo & MoCo - but the
organizational principles don't dictate or necessitate incorporated
bodies. Look at the typical standards bodies - or the ASF - or other
models that have similar structures of hierarchy with more
'consortium' type models.
Also, mozilla super reviewers are not necessarily MoCo employees (I
haven't looked at the list in a while, but IIRC, most of them aren't).
> Drupal, by contrast, is a flat-hierarchy, bazaar-style project,
> with no one entity controlling the direction or governance of the
> project's development. The Drupal Association is removed from
> setting this type of direction, by design. It's the textbook case
> of herding cats. ;)
Drupal isn't a flat-hierarchy. Again, see above.
> Therefore, we need a completely different model: it's 100% in our
> best interest to *spread around* the domain knowledge and
> development process as much as possible, rather than entrusting it
> to a small handful of people. We have absolutely no guarantees that
> domain experts will remain as such. merlinofchaos might leave the
> Drupal community to become a world-renowned novelist, or
> quicksketch might take off and go backpacking around Europe for a
> year. When our menu system maintainer went AWOL, our only recourse
> was to start over completely over from scratch again. We should do
> everything we can to ensure that this does /not/ happen again.
I'm not advocating single points of failure... again, I would
advocate additional redundancy. The key motive here being essentially
formalizing the structure that you alluded is already in place - with
the end result being formal help, and responsibility distribution
outside the current core committers.
Truth is, we're not so different. Mozilla has *thousands* of
contributors ... they're an older, bigger project... and I think we
can stand to learn from them as well as others out there. Shoulders
of giants 'n' all that :-)
James Walker :: http://walkah.net/ :: xmpp:walkah at walkah.net
More information about the development