[development] Perm for setting RTBC - Re: RTBC - how does it work?
drupal.beginner at wechange.org
Mon Jul 2 15:12:00 UTC 2007
On Monday 02 July 2007 22:34, Angela Byron wrote:
> The biggest argument against this that I can think of is that most of
> the people who do these kinds of good patch reviews are also some of
> our best developers (Jeff Eaton, chx, Moshe...). And instead of
> developing new cool features for Drupal, or fixing particularly
> gnarly bugs, they would now be collectively spending their time not
> only reading every single issue in the queue, but also thoroughly
> testing every patch in the queue, enough to give their blessing.
> Giving patches a thorough testing is A LOT of work -- at least a half
> an hour per patch for anything non-trivial -- and the more this is
> spread around, the better.
Read carefully my proposal again (if you so wish!)
Right now, the guy who registered two hours ago could bump any half-cooked
patch onto Dries' lap.
So does anybody else who does not even know what Drupal's coding standards
So I proposed for the perm to be handed out *generously* to good reviewers
('good' is relative, it can be any threshhold that experience will dictate is
the best one to adopt).
AND it still does not prevent other people from reviewing patches and
"Hey! I don't have the RTBC perm, but after thorough review, I think this
patch is RTBC. Please any more experienced reviewer to review my review and
actually set this as RTBC"
If anything, it actually lessen the workload on the second tier of developper
(the much larger tier, just below the first tier consisting of the core
commiters): they only only need to spend time on patches for which the third
tier of reviewers (at the bottom) have shouted (but not set) "This is RTBC".
It is a bit like adding a level between PNR and RTBC.
PNR is the responsibility of everyone, including today's newcomers (third
RTBC is the responsibility of the core commiters (first tier).
and the level in between, the PNR patches for which one has shouted
"RTBC" (much fewer in number than the PNR issues) is the responsibility of
the very wide second tier developers.
This solution is not the panacea. There are other interesting solutions that
are being voiced to solve the perceived problems.
But in addition to the other solutions proposed, a proper use of this perm can
only help lessen the workload on anyone who is above me in the hierarchy of
the coders' meritocracy.
Because we and the world need to change.
Intimate Relationships, peace and harmony in the couple.
More information about the development