[development] Intelligent use of time (Re: Perm for setting RTBC

[Derek Wright]

On Jul 2, 2007, at 4:49 PM, Augustin (Beginner) wrote:

> Either they are going to get committed, or they are not.

Right (more or less).

> If they are not, the earlier coders know this, the better: they'll  
> stop
> earlier wasting their time on that particular issue.

Totally agreed.

> If they are, why not commit them straight away, as they are being  
> set RTBC
> while the patch still applies.
>
> Constantly re-rolling patches also takes time.

Absolutely.  This is a *huge* time sink for people attempting to work  
in the core queue.  Many patches never even get off the ground  
because of the immense effort it takes to keep your patch constantly  
re-rolled.  For example, Eaton and I completely gave up trying to  
solve any of the problems with the $node object in D6 since we knew  
neither of us had the time to fight this (losing) battle.  I'm not  
sure if the core committers fully appreciate what a giant,  
frustrating pain in the ass this can be.

The bigger the RTBC queue, the more this is a problem.  Anytime one  
of the 60 goes in, chances are good that a large percentage of the  
other 59 are broken again.  This constant re-rolling requires  
exponentially more reviews and testing, etc.

> That was the point of what I proposed. Dries complains it takes a  
> lot of his
> time to review RTBC patches. I say: let's have fewer of those, and  
> have them
> better reviewed, having culled the unwanted patches much earlier in  
> the
> process. This way fewer make it to the top, and the commiters have  
> fewer to
> review themeselves and can commit them as they are set RTBC.
> This leads to shorter queues, less needs to constantly re-roll  
> patches, less
> frustration, less time elapsed between drafting the first patch to the
> commit, etc.

Whether or not we do it via a perm or something else, I do think we  
need a shorter RTBC queue.  If it's really RTBC, it either needs to  
go in quickly so life can move on, or it should be killed or  
postponed.  Lingering in RTBC sucks for everyone involved, spreads  
our development effort way too thin, and leads to much frustration  
when the dozens of hours you spent trying to keep your patch RTBC are  
wasted, and the code freeze comes with your issue still sitting  
there, light green, to be unceremoniously bumped to the 7.x-dev  
queue... (needing, you guessed it, yet more re-rolling as soon as  
development opens up again).

I'm totally sympathetic to the "we can't solve these social problems  
with technology" argument.  But, we must try to solve them.  I didn't  
know the history of the dawn of the RTBC status.  That's  
interesting.  But, IMNSHO, what we have isn't working great, and it's  
wasting a lot of developer effort.  That isn't to say D6 isn't going  
to rock, or that Dries or the other core committers are screwing up.   
I don't mean it's not working to generate good releases of core.  I  
mean it's not working since it's wasting vast amounts of developer/ 
reviewer time and energy, and that necessarily means limiting the  
total progress we could be making with Drupal. Think of how much  
better reviewed, tested, implemented, and documented D6 would already  
be if 1/4 of the effort that was wasted on RTBC'ed patches that won't  
get in was spent on the issues that did make it in.

If we had a smaller set of issues that the people willing to deal  
with core were focused on, with clear direction that "if this is done  
right, and properly reviewed, it'll go into DX" earlier in the cycle,  
and we didn't just have to individually work our asses off trying to  
scratch our own itches with little or no input, I believe we'd all be  
better off.

I still don't have great concrete suggestions, so call me "meta" and  
"all talk" all you want.  But I'd like to support Augustin's  basic  
intentions, and resist the "the only solution is for everyone to shut  
up and work harder" style of replies this meta thread is getting.   
Pardon the cliche, but we need to work smarter, not harder.  We're  
all amazingly sharp people, able to solve all sorts of complicated  
problems when it comes to hacking code.  Let's put some of that  
creativity into the meta problem of our development process.  It's  
already pretty good, and a big part of what attracted me to working  
with the project in the first place.  But it most certainly *can* be  
improved, so let's not cling to the notion that we're doing the best  
we possibly can, and those who complain just don't understand.

Thanks,
-Derek (dww)


p.s. When I say "wasted efforts on RTBC'ed patches that won't go in"  
let there be no confusion.  Certainly you can continue to improve the  
patch, and if someday it's going to get considered for core again,  
it's starting from a stronger foundation.  And you learn as a  
developer by going through the review process.  None of that is  
wasted effort.  I'm just talking about the constant re-rolling,  
constant re-review, re-testing, etc, etc.  *That* is the wasted  
effort I propose we try to save.