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.