[development] Perm for setting RTBC - Re: RTBC - how does it work?

[Neil Drumm]

On 7/2/07, Dries Buytaert <dries.buytaert at gmail.com> wrote:
>
> On 02 Jul 2007, at 19:07, Augustin (Beginner) wrote:
> > It is obvious that you three cannot cope with the work load:
> > http://drupal.org/project/issues?page=3&projects=3060&states=14
>
> Where is the rule that says the queues must be empty?  During the
> Drupal 5 development cycle, we also had 3-4 pages worth of patches
> that are RTBC.  It's not uncommon, and I don't think it is
> problematic (but I agree that it can be frustrating).
>
> All in all, I don't think your assessment is accurate.  As long we're
> making good progress on one or more fronts, I think we're in good
> shape.  Committing more patches makes it harder to keep on top of
> things, make it harder to maintain the quality of the code,
> encourages politics, etc.
>
> Either way, tt's *not* my goal to commit all patches.  It's my goal
> to create a great release.  This means I prioritize patches.  We have
> a lot of great new features in Drupal 6 and at the end of the day,
> that's what count IMO.

I don't think that reducing the workload by setting up barriers is a
good idea. Premature RTBC was not really a problem in my experience.
People learn to do the right thing; I can't think of anyone I've had
to consistently correct. I did relax the rules as the 5.0 release drew
nearer since the point is to get reviews done and not argue about
statuses, which discourages developers.

I had weeks when I would review a lot of patches and those with few
patches, the size of the queues actually stayed relatively consistent.
My theory is that contributors keep a consistent mental load of
patches in the queue, so the number of patches stays consistent.

I believe reducing our queues is not something software will solve. It
is a human "problem" that needs a human solution.

Automated tests would change the queue size to a smaller constant, if
at all. They are are good, but would not alone lead to a very small
number of issues.

Making reviewing easier will help. I could probably come up with a
laundry list of small improvements to project module, but that won't
help dww or other project module people. A lot of it is probably in
the project.module issue queue.

The real winner would be a community change to increase the value of a
review. Writing a patch solves your problem. Reviewing help solves
someone else's problem. That is why I think there are more patches
than reviews.

-- 
Neil Drumm
http://delocalizedham.com