[drupal-devel] more core comitters

[Robin Monks]

Another good way to help out, is for the patchers themselves to check their 
patches. I always test my patches on as many systems I can. Usually on my 
own localhost (The free Xitami, MySQL express, PHP 4) and on a linux box 
(sometimes my own, sometimes a donated one).

This way, I can confidently say that my patch was tested and worked on these 
various systems.

Robin

On 7/29/05, David Barnes <eglish at gmail.com> wrote:
> 
> 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/
> >
> >
> 



-- 
Robin Monks,
CSL Web Administrator
robin at civicspacelabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drupal3.drupal.org/pipermail/development/attachments/20050729/9dbf59fb/attachment.htm