[development] Very concerned over Drupal's core development
Daniel F. Kudwien
news at unleashedmind.com
Wed Apr 29 00:07:10 UTC 2009
I agree with Earl and Darrel, many patches are derailed with endless
debates. The question is whether that is good or bad, because the context
is missing.
I can't speak much about the past, but is it possible that core's
development process changed drastically?
We introduced an awesome testing framework that ought to increase the
quality of code that is committed to core. However, we are still
introducing new core bugs (take "FAIL." [1] as an example), despite being
reviewed by many eyeballs and having tests.
I think this is caused by the steadily increasing complexity of Drupal core
- and - by a lack of reviewers that *really* understand core, use-cases in
contrib, many sub-systems (not one), and all implications of a core patch.
This is the real issue (I believe) Karoly wanted to raise originally.
I am not sure whether sub-system maintenance teams will lead to an
improvement of this situation. Completely contrary to this proposal, I
think our issue is that we are lacking the opposite of domain experts:
Drupal core contributors/maintainers/reviewers who understand every single
bit of core and potential implications of a changed bit.
For the sake of clarity, I have revised Dries' "Drupal learning curve"
graph, because I think the important part - the part we are really talking
about - is missing:
http://www.unleashedmind.com/files/drupal-learning-curve.png
Adding new people above the "Core contributor" threshold is what we are
mostly doing currently. However, it is my impression that there are very,
very few people above the "Trustworthy for core maintainers" treshold. Even
less, if you only count people who are known to be "trustworthy" for more
than one sub-system. It is possible that you counted only one person (or
less?) when climbing up the further tresholds.
Maybe that is the issue we are facing? Patches languish in the queue for
ages, because some sub-system maintainers subsequently chime in, each one
needs own treatment, other contributors chime in, trying to understand the
issue, the patch is re-rolled all over again, a branch maintainer shows up
who questions the entire approach, and finally the patch may or may not be
committed -- still lacking review by someone who understands all changes and
implications of the patch.
Given all other proposals in this thread, my guess is that adding more
maintainers to core might really be a step in the right direction: Handing
out responsibility (that comes with a fair amount of power) to core
contributors who are already known to be trustworthy (in more than one area)
will most likely let them advance in other areas, climbing up the
"treshold-ladder" - not only, because people will start to ask about
reviews/commits for arbitrary patches.
Equally, this action could be done now.
[1] http://drupal.org/node/446742
Thanks,
sun (who hopes to have reached macro-level with these thoughts)
More information about the development
mailing list