I'd like to get these time thresholds for RTBC patches formalized and documented on the issue statuses page:

Copying from @catch's announcement on http://groups.drupal.org/node/179984 :

  1. Minimum 3-5 days in RTBC
    I'll also try to leave a window of at least 3-5 days for any patch that's not trivial before committing it, especially if it's the first time that issue has been at RTBC. People who keep an eye on the RTBC queue can use this time to perform a final review and/or knock things back to needs work before they're committed. Note that Dries and webchick may handle this differently, and we can always re-open issues for follow-ups and/or roll-backs to repair breakage.
  2. Maximum 4 weeks in RTBC without a review from a committer
    At the other end, I'll try to make sure no patch stays in the RTBC queue for more than 4 weeks without at least being reviewed by me. To keep that manageable I'm going to prioritize the RTBC queue above my other Drupal core activities, (like reviewing other patches or working on my own).

@catch applies these thresholds to all RTBC patches since he became core maintainer. With great success.

Tasks

  1. Community agreement on that this is a good thing.
  2. Agreement from @Dries, @webchick, and possibly @GáborHojtsy (ahem, especially @Dries, who's known for even committing non-RTBC patches... ;))

Comments

sun’s picture

Assigned: Unassigned » sun
sun’s picture

Issue summary: View changes

Updated issue summary.

klausi’s picture

The question is: does formalization solve any problem here? AFAIR we always had a problem that RTBCs were lying around for a long time. Core committers have a hard time to keep up to date with all the RTBC issues, if they want to do anything else besides looking at the drupal.org issue queue all day long. So IMO catch is currently delivering a super human effort to keep the RTBC issues under control, but this is not sustainable and IMO leads to burnout.

I know this has been discussed way too often, but I'm gonna say it anyway: we need subsystem core maintainers (with commit access!) for relatively good decoupled and independent core areas (I'm looking at poll.module or the "documentation" category which has 6 mostly trivial RTBC issues right now).

Yes, now you may shoot me.

sun’s picture

@klausi: Availability of core maintainers is a completely different issue than setting up rules for how (or rather "when") to deal with RTBC issues/patches. The proposed thresholds here apply always, regardless of how many core maintainers are currently available, or how many of them. Let's focus on the actual proposal, please. :)

klausi’s picture

Ok, some focus:

Rule 1) does totally make sense and is a no-brainer. Nothing to discuss here.

Rule 2) will only increase pressure on core comitters, IMO 4 weeks is not realistic in the current single branch committer process. So I would phrase it like this:

Priority to RTBC issues
At the other end, I'll try to make sure that the RTBC queue stays as short as possible. To keep that manageable I'm going to prioritize the RTBC queue above my other Drupal core activities, (like reviewing other patches or working on my own).
sun’s picture

The way @catch formulated the second threshold actually has an important background:

There have been a lot of issues in the past that were stuck on RTBC for almost years, without any kind of reasoning provided by the assigned core maintainer on what's wrong with the respective patch or why it wasn't committed yet.

The max threshold addresses exactly that. In a sense, it could be mapped to your "pressure" thinking, but entirely differently, in fact, removing pressure:

It's perfectly OK if you're not available at times; but you do understand that the community wants to move forward, and so any issues that are blocked specifically on you as a core maintainer may be tackled by someone else, if it takes too much time for you to respond.

Makes sense?

grendzy’s picture

On day 30 of RTBC with no activity, System Message automatically commits the patch. :-P [Edit: yes, I'm kidding].

xjm’s picture

Well, I think we can simultaneously adopt this and also acknowledge that:

  • Core committers are volunteers like the rest of us.
  • Certain issues will have extenuating circumstances.

From the outside, it seems like Dries, webchick, and catch have a pretty good balance for getting things committed. RTBCs have not been going stale or blocking other work these past 4 months, and the only patch that I saw get more than a month old was API docs cleanup for trigger. :P So I think the 4-week point isn't unreasonable. (Hopefully they can comment on whether that's how they see it as well. )

I'm definitely most concerned with point 1, because there are a lot of people who review the RTBC issues every day or few. When an issue goes from NR (or less) to committed in less than 24 hours, that disrupts the review process and can cause headaches for everyone if followups and rollbacks are needed. Plus, the people who review RTBCs also save the core committers time by helping filter out issues that are definitely not ready to be committed. :)

xjm’s picture

Issue summary: View changes

Updated issue summary.

xjm’s picture

Issue summary: View changes

Updated issue summary.

xjm’s picture

Issue summary: View changes

Updated issue summary.

TR’s picture

How about automatically escalating the priority of an RTBC if it has been in the queue too long? This is similar to what has been instituted in the project applications issue queue. (Define "too long" however you like.)

I'm against automatically committing an RTBC patch after 30 days, as suggested (perhaps jokingly?) in #6.

Personally, I'd rather not formalize how long an RTBC patch can exist in that state - the core committers don't need that additional pressure. This should be more of a "guideline" rather than a rule.

Gábor Hojtsy’s picture

I was called out in the opening notes, so here is my take on this policy vs. Drupal 6. I'm not sure these rules are good to apply to Drupal 6. Yes, there are painfully old issues in the Drupal 6 RTBC queue but people finding those patches in the Drupal 6 RTBC queue also tend to push them back to needs work because there is no automated testing in Drupal 6 so there is a lot more manual testing required before a patch can be considered ready. In a sense, Drupal 6 would need two distinct RTBC states, the (a) at least someone thought this worked/looked good and (b) many people thought this worked/looked good.

It is not very rare in the Drupal 6 RTBC queue for issues breaking backwards compatibility or not taking fixing the same bug in Drupal 7 or 8 into consideration because people just want to get their stuff done quick. I've not seen people making reviewing the Drupal 6 RTBC queue a priority for a year plus so it became part of the process to leave RTBC issues lingering waiting for even more feedback before they can get committed.

As for Drupal 8, working on the Drupal 8 Multilingual Initiative I'm working with a bazillion of small patches to get to goals. They in and of themselves need some discussion so merging them is often not an option. However, leaving them sitting in the RTBC queue for more than 3 days IMHO is a mistake and hampers the progress of the initiative considerably. D8MI needs a constant stream of patch flow to reach even some of its goals. I'm trying my best to feed that flow from the queue both by producing patches and trying to help people produce them, but I clearly need more reviewers and then more timely core committer attention. I understand the motivation for 3 days, however D8MI patches are often between the trivial and mid-complex and are very far from the high complexity of patches proposed by CMI or WSCCI. So I'm not sure there is a one size fits all solution there.

xjm’s picture

The point about patches waiting 3 days hampering D8MI seems sort of extreme to me. It's 3 days... and more often, any delay is due to the core committer's availability. One can't expect all the patches in a certain category to be committed immediately. Is D8MI using a sandbox? If not, then that would seem like a better solution than saying those patches need to be committed to core right away. And if so, then how does the state of core relative to the sandbox for a few days hamper development?

I agree that D6 is a much harder question because of the lack of a test suite, and I'm less sure about that than D7/8. But maybe the right status for those issues that still need review is Needs Review?

xjm’s picture

On the other hand, maybe it's different when an initiative lead explicitly signs off on a patch. Still, though, I think that expecting patches to be committed immediately is kinda questionable, so it seems like it would be good to have a process for initiatives where an interval of a few days does not hamper work.

Gábor Hojtsy’s picture

@xjm: I was referring to more than 3 days, not 3 days being a problem for the kind of smallish patches I'm talking about. Yes, its core maintainer availability that causes the delay usually. Its also one of the core maintainers who appointed initiative leads and painted desires of big results. If you look at all fixed/closed issues with D8MI you'll see 52 issues at the moment: http://drupal.org/project/issues/search/drupal?status%5B%5D=15&status%5B... There are 262 days since Dries announced me to try and lead a multilingual initiative (the tag was not used before). Comparing those two numbers, its an issue per 5 days on average since May 9th 2011. It is a steep pace, but it is due to the bite sized chunks the work is broken down to. And that defines the "certain category" as you named, the bite sized chunks, not whether it is D8MI or not. I deliberately break it down to bite sized chunks to get stuff in faster and avoid working in vain.

The fact that it is lots of bite sized chunks and more often dependent on each other than not is just the nature of having a "theme" for these patches, the initiative's goals. And what might in fact make it more pressing to review/commit those vs. random other patches is the expectation of the big results. This happened before and will surely happen outside of officially named initiatives. You can think of the DBTNG effort in D7 or when form API was introduced in a haste. It is certainly not politically correct to say that initiative patches should have a fast lane, and I was not suggesting that. I'm rather saying that when there is a stream of dependent patches, the whole thing gets severely delayed if patches are not reviewed and committed in a timely manner.

Yes, people having huge goals can use sandboxes. It would be great to see successful examples of that. In my experience sandboxes make it very easy to go on a path for quite much longer without "outside" review, and the D8MI "team" if there is even one is very-very tiny for that. Recent examples, where the WSCCI people worked on a context system for example for months on and then posted in the core queue which was shot back on shortly. People demanded those issues be discussed and maintained in the core queue. It is not uncommon for core committers to demand further changes or not agree with those who worked on the patch, which makes dependent patches fail and sometimes dependent work that needs to be redone.

We are not just talking about delayed commits. RTBC issues are not universally going through unquestioned. We are talking about delayed core committer feedback.

webchick’s picture

Sorry, but -1. I work on Drupal 7 as much as I'm physically/mentally able to do, given all of the other demands I have on my time. And a lot of that time I'm not spending committing on D7/D8 patches is time spent taking pressure off of catch and Dries either directly (participating in/pushing forward "bikeshed" discussions, escalating issues that need them to their attention) or indirectly (finding out from initiative owners what they need, doing outreach to try and get reviewers involved), to enable them to focus their time better on D8. If I'm held to this standard, other areas of the project are going to suffer. Period.

If the concern is that people are waiting too long for reviews, or too long from initial RTBC to core committer feedback/commit, then what we need is simply a view that shows this information that core committers (and other patch reviewers) can refer to. None of us would EVER intentionally ignore a patch from someone trying to make Drupal better. But often what happens is a testbot re-test marks something "needs work" coincides very closely with us hammering through the RTBC queue, so it moves off our radar. Or the issue gets bumped (maybe someone asking "Why has no one committed this yet?" :P) and so it appears to have only been sitting there for RTBC 2 days instead of 38 weeks, so when I'm doing FIFO processing of the RTBC queue, I miss it. Etc.

We need tools to provide better visibility to problem areas, not more rules governing volunteers' time.

moshe weitzman’s picture

#13 implies that you are preferring those bikeshed discussions over issues that are RTBC already. Thats non-ideal, IMO.

webchick’s picture

Well, for me at least it's a matter of context switching.

When I have 10-15 minutes in between phone calls, that's not enough to really get into the RTBC queue. For that I need more like 30 minutes+, and so I tend to do most of my RTBC queue work in the afternoons/evenings and weekends. However, that 10-15 minute timeframe is perfect for "communication-related" tasks: unsticking biksehed discussions, coordinating with contributors, firing off an email or two, etc. Moving Drupal core development forward is more than just committing patches, and this "soft skills" stuff catch explicitly said he did NOT want to do when taking on D8 co-maintainership, so I try and help off-set those tasks as much as I am able to.

I can't do much to restructure my life so I have more 30+ minute blocks of time. But I'm happy to use my RTBC queue time more efficiently. If i had the ability to sort the RTBC queue by "time waiting in RTBC queue" I would certainly do that. Unfortunately, all I have is priority, time since last comment, and total time an issue has been opened, so often these "chronic" issues can fall by the wayside. This isn't due to lack of dedication, or lack of rules governing my time, but simply lack of visibility.

catch’s picture

There is more to talk about on this but just quickly. At the moment at least I'd be opposed to any formal maximum time at rtbc status. I have made a best effort to keep things under a week at RTBC and that has worked most of the past four months, but a couple of weeks with very restricted free time threw that way off, and that comes down to there being very little slack in terms if committers, which is a different problem altogether.

However like webchick says it would be good to be able to order the queue by time at RTBC rather than last updated so it's actually possible to go through fifo. Also issues that block other issues as Gabor points out, but personally I would just bump those to major if there's an actual dependency (we can add blocking issues to the major tasks definition if we need to) since those get fast tracked by me anyway.

I do personally really like leaving issues RTBC for at least three days though, since it makes a big difference in terms of people being able to look through the RTBC queue for duds and weed them out, including spotting things I would have missed. Not everyone has read that groups post though, and afaik no one's talked to Dries about it directly, but for me at least it feels worth trying to standardize on. However even that there are exceptions - rollbacks, small documentation patches, unbreaking head etc. where it doesn't make sense.

xjm’s picture

It seems like there is a lot of (understandable) discomfort with some expectation of an upward bound. What about the 3-day min time in RTBC, though, outside of the obvious exceptions catch mentions? That's the point that concerns me as a reviewer and developer.

Edit: One would count the 3 days from when the issue was marked RTBC, not when it was last "bumped".

webchick’s picture

I personally think that when core committers have time to commit patches, they should commit patches. If we accidentally screw something up, it's easy enough to revert, or mark something back to "needs work." If I see something RTBC and don't commit it today, then there's a really good chance I don't get to it for another 2+ weeks, thus running into the upper-bound problem which is where most morale problems come from.

webchick’s picture

And for clarification. That 2+ weeks isn't because I only commit patches every 2 weeks. On non-travel weeks, I usually have one decent 4+ hour stint a week, plus a few other 1-hour chunks here and there. But because we don't have a view that shows time spent in the RTBC queue, chances are that other issues will appear that are more on fire (major/criticals), easier to commit (documentation/minor), older (because this issue got bumped with a +1) or whatever other factor that causes them to get passed over during a given commit sprint.

Have I made this clear yet? :) We need a view. That's all we need. Not more rules.

Tor Arne Thune’s picture

I think the maximum time in RTBC should be an individual decision by the core co-maintainers. It's voluntary work after all, and life happens. Also, I can't see any core co-maintainers neglecting their role, so it will probably not become a problem (at this time). But you never know, maybe the Drupal 9 co-maintainer will be a real slacker ;)

The minimum time is a good policy and can be easily implemented.

grendzy’s picture

We need a view. That's all we need. Not more rules.

For max time, I have to agree this is too much to ask of our maintainers. I've opened #1423530: Help project maintainers manage RTBC queue on a first-in, first-out basis in the project queue.

xjm’s picture

Talked this out a bit in IRC. Several folks feel that trying to make this consistent across the board doesn't really get at or explore the underlying concerns, which webchick outlined as follows:

  1. Things can get "stuck" in RTBC for a very long time if they're not critical/major, and not a no-brainer patch.
  2. We do commit things that end up needing almost immediate follow-up.
  3. For initiatives trying to things the "right" way (not off in a sandbox off the grid, but broken up into nice bite-sized, reviewable issues) the longer the latency between RTBC and commit, the harder it is to coordinate.
  4. Core developers want some assurance that their patches are going to get looked at in a timely manner by a core committer.
  5. A very short lifetime between NR and a commit makes developers feel they can't participate in the review process.

I think these underlying concerns are part of why catch outlined the process he did in the original post, and I guess the goal of this issue was to explore whether making it a standard would help reduce some of these concerns. I guess there's not enough consensus that it would. The "better RTBC view," however, seems like a good actionable followup.

Dries’s picture

Assigned: sun » Dries

Assinging to myself so I can comment.

webchick’s picture

Copying a comment from #1216978: Clean up the CSS for Contextual module which is relevant to this discussion:

I just to point out there is absolutely no consensus in the referenced issue that we should add even more barriers to people trying to get their patches committed. And further, that coding standards/documentation-related patches can be much more easily fixed in follow-ups post-commit than standard bug fixes and other types of patches (for example, sun's comments here could easily be a novice task tackled during office hours), so even if there were consensus around that I would strongly advocate using a different rulestick for these types of changes.

We brought Jennifer on as a core committer to help take pressure off of catch, Dries, and I, so we could focus on majors/criticals/other bug fixes, and to help with the velocity of the RTBC queue. Makes sense to let her do her that. :)

The "RTBC defense crew" would be much better served focusing their extremely precious and valuable time on patches that truly need their due consideration: major/critical bugs, non-trivial tasks, API changes, etc. We should let the easy ones go in quickly, both to help keep morale of core contributors up (if a simple CSS restructure takes 100+ comments, that sends a huge red flag to spend volunteer time elsewhere), and worst-case to help fill the novice queue with simple tasks for for new contributors in the case where a committed patch requires minor tweaks or clean-ups.

Treating all of these patches the same, from a typo fix to an API change, is completely silly. Let's focus that energy where it's most valuable, get the RTBC queue moving. That's going to make everyone happier.

sun’s picture

  1. The issue you linked to is not a trivial task. Definitely not on the same level as fixing a typo.
  2. This proposal actually contains an exception for trivial patches. Hence, committing (trivial) novice stuff early is perfectly fine.
  3. There's no such thing like a "RTBC defense crew". There are patches. And there are people who happen to care for certain topics, and thus, for certain patches.
  4. Each issue that unintentionally spawns into one or more follow-up patches or even entire issues to fix regressions ("fix the fix") sends an even more huge red flag to contributors and users about the overall state and quality of Drupal.
Gábor Hojtsy’s picture

Each issue that unintentionally spawns into one or more follow-up patches or even entire issues to fix regressions ("fix the fix") sends an even more huge red flag to contributors and users about the overall state and quality of Drupal.

Oh my god! If Drupal 8 is not the place to be able to make mistakes, then where it is? If it is a bad message that developers are making mistakes then we should encourage more people *not* to work on core to improve Drupal's PR. After all those who don't work don't make mistakes. Many people understand this and rightfully stay away from Drupal core. We put up bazillions of gates and checkpoints to avoid making mistakes and we still make mistakes! So then we are even more terrified that we made mistakes despite all those checks and gates! So the solution is to add more of those constraints! Right? Or at least enforce those constraints even more aggressively!

No. I think the solution is to understand that we are *human* *volunteers* working on a *development* version and just accept the consequences.

webchick’s picture

I really, really wish Drupal.org had a "+1000" button for comment #26.

Michelle’s picture

Round of applause anyone? :)

sun’s picture

Title: Formalize min/max time thresholds for RTBC patches » [policy] Formalize min/max time thresholds for RTBC patches

Yes, #26 is right in that it is not the intention of this policy to turn the current development branch into a stable branch or anything like that.

However, the essence of what I argued for in #25 is:

  1. Each commit that requires to fix unintentional regressions is a sign of poor quality.

Because: It is most often a matter of "luck" and coincidence that a (late) reviewer will point out fundamental problems with a suggested change. (The list of examples is so large, I wouldn't even know where to start.) In turn, it's the same matter of luck that makes us aware of problems before a potential release.

Because: The moment we switch the context from Drupal HEAD to something else - i.e., any other software - I bet that almost everyone can very well relate to the "habit of blaming" the developers upon encountering any regression. To outsiders/newcomers/bystanders, but also (though less important) to insiders, every regression, by nature, leaves the impression of "Did they even have any idea of what they're changing?"

I'm not saying that everything we do and commit has to be picture-perfect. I'm saying that we have a peer-review workflow for very good reasons, and this policy only attempts to formalize that policy in a way to make it transparent for everyone, regardless of whether you're an oldtimer or newcomer.

I'm also not saying that this policy will prevent all mistakes from happening. Nor am I saying that Drupal core is a software product that isn't run by volunteers. I'm saying that Drupal core, especially because it is driven by volunteers, uses a peer-review process to ensure that we're progressing in the right direction, without regressions. It's exactly that community-based peer-review process that makes the Drupal project the powerful player in the market, and that is what essentially enables us to find the right answers and proper solutions for complex problems.

Preventing mistakes, if possible, is part of human nature. It is what made humanity evolve.

Gábor Hojtsy’s picture

Preventing mistakes, if possible, is part of human nature. It is what made humanity evolve.

I agree with this statement.

Each commit that requires to fix unintentional regressions is a sign of poor quality.

I don't agree with this statement. (But thankfully we have this peer review process so we can discuss :).

Looks like we have different tolerances for regressions in a version of Drupal that is very actively in development. There are lots of things being done to avoid regressions, including a backport process, where applicable patches are tested against multiple Drupal versions (and fixes possibly getting into production even before the development version of Drupal is out), maintainers looking for subsystem expert feedback on issues that relate to certain systems, the major/critical limits that ensure bugs are fixed before new things get in even if the original feature developer is unwilling to provide fixes, etc.

Overall I don't see that my opinion changed any since my post above, still agreed with webchick.

Gábor Hojtsy’s picture

Issue summary: View changes

Accent.

mgifford’s picture

So can we mark this as policy @Dries, @webchick, @GáborHojtsy and then close this issue?

ianthomas_uk’s picture

Sorry to (potentially) restart this discussion, but I doubt this is an issue that will ever go away. Obviously I'm not a core maintainer, so sorry if my assumptions about the work they get or good ways for them to work are wrong, but hopefully they are at least useful ideas.

I'm not in favour of a minimum RTBC time as a matter of course, because I don't think it's a particularly effective way of getting "final reviews" and it definitely has costs. Delays in committing:
- can delay the start of work on followup issues.
- can add extra work to other issues, e.g. when they are using APIs that are changed by the RTBC patch or when patches fail to apply.
- are demotivating, especially for new contributors.
A long RTBC queue also reduces the visibility of issues that may need further review. I'm not saying I expect all patches to be committed within 3 days, just that adding an artificial delay seems counter productive.

To encourage "final reviews" on potentially contentious patches:
- ping contributors known to have an interest in the relevant area or who have recently argued against the patch in the issue.
- apply a tag to Needs Review issues that are almost ready, maybe something like 'Tentative RTBC'. A script could then set the issue to RTBC after a set time. If you don't think the issue should be RTBC, then you would remove the tag.
- get the issue mentioned in TWIDC.
- delegate some of this responsibility to initiative leads / module maintainers.

The demotivation problem could be helped by commenting on issues that aren't ready for immediate commit, so it doesn't look like they are just being ignored. e.g.
"This is a disruptive patch, so will need to wait until at least xxx before we can consider it"
"This could use some more community feedback, so I'll leave it for a few days before I review it"
"This looks fine to me but is a complicated patch. I'll give people another few days to review it, but if no one finds any problems then it should be fine to commit"
(this last one indicates that the patch has already been reviewed by a core maintainer, so if no one did raise any problems then another core maintainer could commit it without doing their own review).

sun’s picture

I agree with @ianthomas_uk.

It was a good idea to try this approach in production, but in the meantime, the downsides of it are clearly visible; a very long RTBC queue, and due to that, much more unnecessary re-rolling of patches. In particular, it is detrimental for efforts that are being split into multiple issues for the sake of making smaller changes review-able.

In essence, I agree with everything @ianthomas_uk said, just not on the "add yet another Needs xyz tag" part ;-)

Especially on the "be verbose" part. That appears to make much more sense, because

  1. Issue participants understand what's going [not] on instead of silence.
  2. A verbose comment clarifies on one maintainer's own thoughts.
  3. A verbose comment keeps the issue at the top of the RTBC queue.

I like the initial three suggestions of verbose comments provided by @ianthomas_uk, they certainly cover the most common situations already.

If desired and if it would help, we can adjust Dreditor to add a set of maintainer feedback buttons that would insert those comment templates. (It's not a problem at all if those verbose comments are always the same, as long as there is feedback.)

ianthomas_uk’s picture

It's not a problem at all if those verbose comments are always the same, as long as there is feedback.

It can even be a benefit for responses to always be the same, as it reduces the chance of a comment being taken personally / misunderstood.

The tag is also the part that I'm least sure about. The idea is to offer a channel where anyone can ask for those "final reviews" so people can't complain that they didn't get a chance to review something. Maybe this could be left to TWIDC.

ianthomas_uk’s picture

In particular, it is detrimental for efforts that are being split into multiple issues for the sake of making smaller changes review-able.

That's worth highlighting on it's own actually. Slow commits encourage monolithic patches which are harder to review, leading to lower quality reviews.

catch’s picture

The length of the RTBC queue has very little to do with minimum time at RTBC, I've been the only person following that with any strictness (and I cut it to ~24 hours or less for any remotely straightforward critical/major issue), it's more about sheer volume of patches. Can't easily get stats for how many issues are RTBCed per month or similar, but for commits there's a clear upward trend:

$ git log --pretty=oneline --since="one year ago"| wc -l
    4425
$ git log --pretty=oneline --since="two years ago" --before="one year ago" | wc -l
    3559
$ git log --pretty=oneline --since="three years ago" --before="two years ago" | wc -l
    1725
$ git log --pretty=oneline --since="four years ago" --before="three years ago" | wc -l
    1910
$ git log --pretty=oneline --since="five years ago" --before="four years ago" | wc -l
    2866 (peak Drupal 7)
$ git log --pretty=oneline --since="six years ago" --before="five years ago" | wc -l
    1273

There's currently about 90 RTBC issues in the queue, but the least-recently-updated of those was 8 days ago. When I posted http://groups.drupal.org/node/179984 that was more like 3-6 weeks. There's also been 222 commits in the past two weeks, which doesn't include issues knocked back to CNW/CNR.

Stuff that would be immediately useful:

1. A column on the issues list that has the timestamp the issue was first RTBCed, so it's possible to sort the queue on that as well as when it was updated. This would help to flush out issues that are stuck in re-roll hell. I sometimes go through the queue FIFO and I know Alex does more than me these days, but there's no way to properly do it FIFO.

2. #1952058: [META] Retesting stale RTBC core patches is now running every 24 hours, but we could probably improve on that - i.e. running only the 'does it still apply check' after every commit. Running all unit tests after every commit, analyzing patches in the RTBC and CNR queues to see which will conflict with each other. Lots of possibilities.

3. Additional core committer and/or funding.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

catch’s picture

Status: Needs review » Closed (outdated)

RTBC queue is still hard to keep under control, but minimum RTBC time is only an issue for certain patches, and maximum time without feedback we have better tools to keep an eye on these days like the 'status changed' column in the queue.