[drupal-devel] more core comitters

[David Barnes]

After reading the discussion thus far, it seems the bottleneck for
development is the testing/reviewing/benchmarking of patches, not the
amount of core contributers.  So how about we create handbook page(s)
describing standards or guidelines the core developers  want to see in
the commenting of the patches.  This would hopefully help eliminate
the '+1' comments and possibly prodive some useful documentation if a
committed patch winds up causing problems.  Also if we have certain
conventions, we could have patch testing phases.  For example, 'patch
phase 1' would be an initial commit of a patch.  'Patch phase 2' would
someone reviewing the patch to make sure its fits with drupal/PHP
conventions, doesn't break drupal, and is still relevant to the
version of Drupal the patch is for.  'Patch phase 3' would be comments
on the testing of the patch, like how well it tackles the actual
problem, how well it functions with/within the current system, and how
well it is written (i.e. not a hack job).  And 'patch phase 4' would
be some simple benchmarking.

If its clearly documented on how it should be done and presented, that
would allow more people to help with patches, and letting the core
contributters focus on the acutal numbers, instead having to make the
numbers themselves.

On 7/29/05, Dries Buytaert <dries.buytaert at gmail.com> wrote:
> 
> On 29 Jul 2005, at 11:17, Gerhard Killesreiter wrote:
> >> I said this before and I'll say it again: the problem is not the
> >> committing but the reviewing.
> >
> > No, one affects the other. In the past weeks I haven't reviewed any
> > patches because I knew that both you and Steven were too busy to
> > commit
> > them and that by the time you'd have the time, I'd need to look at the
> > stuff again. This is discouraging. I am pretty sure others are
> > thinking
> > the same.
> 
> If a patch is tested, reviewed and benchmarked it takes me one minute
> to process it.  In such a scenario, I can commit up to 60 patches in
> an hour, or empty the patch queue in an evening.  This won't happen
> as I often spend 30 minutes testing, reviewing and benchmarking a
> particular patch.  Testing big patches like the node revision patch
> easily takes me 1 hour.  The node revision patch could have been
> committed weeks ago if only enough people cared about it.  Adding
> core committers doesn't help.  Adding more status flags to the
> project issues makes a patch's status more explicit (good) but
> doesn't change the fact that we'll need to spend a couple hours
> testing the node revision patch.
> 
> >> I tend to ignore +1's unless I sense that the commenter put time and
> >> effort in evaluating a patch.
> >
> > See above for my reasons not to invest both. Contrary to what Bèr
> > believes, I have no time to waste either.
> 
> I'm perfectly happy with you -- or other people -- not investing time/
> energy in reviewing patches.  If you believe testing, reviewing and
> benchmarking patches is a waste of your time, then I guess I "waste"
> at least 2 hours of my time a day -- especially because many reviews
> go unanswered.  Make no mistake, I'm happy to "waste" my time
> reviewing other people's work, including yours.  :-)  Saying that
> less gets done during my absence, just means that fewer patches get
> reviewed.  If the node revision patch (our running example) was
> tested extensively, I could commit it from Italy.  For example, I
> committed some patches earlier today.  However, when I don't have the
> time it takes to test it (like now), it sometimes goes unreviewed,
> and hence, uncommitted.
> 
> > I am pretty sure that these can be minimized. We've had three core
> > committers in the past and it worked.
> 
> Not quite.  Steven and Kjartan let me review their changes first.
> Steven only started to commit "independently" one year ago, and even
> now, he still consults me about bigger changes (and often, I consult
> him too).
> 
> --
> Dries Buytaert  ::  http://www.buytaert.net/
> 
>