[development] Intelligent use of time (Re: Perm for setting RTBC
drupal at dwwright.net
Tue Jul 3 04:28:00 UTC 2007
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
> earlier wasting their time on that particular issue.
> 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
> 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
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.
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.
More information about the development