[policy, no patch] 8.0.0 release candidates, release, patch versions

Wow, great that this is being discussed now, and I think the issue summary and comment #2 both look great! Seems pretty clear and very rational.

No idea about the questions in #3. Good luck with those. :) But maybe you don't need to spell out or think of a response for every possible contingency... I think the policy is generally clear that 8.0.x should be released a short time after all the Critical issues are fixed, and that if possible it won't be released with critical problems, which is the main idea, right?

Would be important to factor in some kind of typical work required up to the release.

Final beta

• We'll almost immediately tag and release a 'final' beta once zero critical issues remain.
• The first release candidate, will not be tagged until we've successfully stayed at 0 critical issues for ~10 days

Release candidate

• Further release candidates will not be tagged until we've successfully stayed at 0 critical issues for ~10 days
• If we are not churning through critical issues, we'll allow code-style cleanups to be committed during this period. These can be very disruptive to other patches but have an extremely low chance of introducing regressions.
• Apart from that, only critical issues, or major issues with very low chance of disruption/regression on a case by case basis will be committed, everything else will be deferred to 8.0.1 or later

Where does UI / string freeze comes in? Sounds like that would not be "code cleanup" so based on this policy both would need to happen before/at RC1. That makes sense because RC1 may become the release if there are no more criticals. Do we provide a window though for translators and UI fixers to have time before a release may hit? When should those earlier deadlines be cut? We don't exactly want to focus people on working on UI cleanup / UI text cleanup now, right? We'd love people solving critical issues swiftly all around. However if there is no space / process for fixing the UI then (those are not critical) then when is that going to fit in?

I'm not sure how broad this issue wants to go, but the IS talks about a 8.(N+1) version, but not about a 8.(N-1) version. i.e. backporting of bug fixes. But I suspect that's out of scope for this issue?

In most cases, won't these just be git cherry-pick?

We could say we don't commit any issues to 8.1.x without a patch that applies cleanly to 8.0.x as well.

String/translation freeze is not really helped with the 10 days prior to the last RC, because localize.drupal.org will only get releases that are cut, not dev versions, because they change all the time (you don't want translators chase strings that may only last days in the code :). I think its important to make this clear then because those writing books who want them to get out at an early time as well as translators and even more so those who want to fix UI/strings will need to plan with this then.

Thanks for the writeup, catch. I think this is a great start to the discussion. I have a couple of concerns:

- I'm concerned that "no new criticals discovered for 10 days" for each RC, and therefore 20 days for 8.0.0, is a standard that can result in pushing a D8 release out much farther than it needs to be. I'm quite confident that critical issues will continue to be discovered even after 8.0.0 is released. Critical issues are still being discovered against D7, years after its release. Can we change this metric to only including really bad (definition of that TBD) criticals? As an example, I think #2181811: System info can become inconsistent if hook_system_info_alter() makes a module required and #2368975: ElementInfoManager::buildInfo() processes info data on every request are legitimately critical issues, meaning that I think it makes sense to hold up RC1 on stuff like that when that's known ahead of time. But I'm concerned if discovering new issues like that keeps pushing out our release, because there's probably no end to that process.

- I also don't see why we need a 10 day critical free window to go from RC1 to RC2. I think something more like 2 days would be sufficient. If we release RC1, then 3 criticals are discovered in the first 3 days, and we fix them a few days after that, why not release RC2 right away (or maybe after a 1 day commit freeze)? Wouldn't it be better to keep RCs flowing quickly, so that we get faster feedback from the sites out there that will be chasing them?

Since at that point we think we have the actual release ready this seems OK to me (i.e. there's no dilution of 'ready when it's ready', it's more 'released at a specified time after being deemed ready' which is extra time)

I don't think this makes sense. For D7, we had a 2 week window (Dec. 21, 2010 to Jan. 5, 2011) between announcement and release, but I heard from webchick that in hindsight this was too short, and that the people organizing the events would like more time, maybe as much as 2 months. Delaying a D8 release by 2 months after it's already fully ready seems foolish to me. I think it would be more practical to announce a date that's 2 months out once we reach something like RC2, and then release 8.0.0 on that date even if there are some newly discovered criticals that need to be pushed to 8.0.1.

While I certainly agree that we want to avoid those situations if we can, I think it can be dangerous to base current/future decision-making on those specific mistakes of the past, for two primary reasons:

1) We've introduced numerous process changes since then to avoid exactly those problems. Among them:

• We now do monthly core release windows, rather than "whenever it feels right" release windows. 5+ months between bug fix releases will literally never happen again (with the possible exception of Drupal 8 RC releases, if the plan in the issue summary is followed, and we never make it 10 days without a new critical being found).
• Drupal 8.x was branched only a couple of months after Drupal 7.0 was released, and that contributed difficulty in fixing critical issues in D7. But we've already established that we're not branching 9.x until most likely years after Drupal 8.0.0's release, and the above proposal suggests holding even 8.1.x for at least a couple of months. This problem therefore seems to be mitigated as well.
• We've also agreed to wipe the highly critical/critical security issue list prior to Drupal 8.0.0 RC1. So while a last-minute security problem with a 0-day exploit available could always happen, I think with Drupal 8 we're doing absolutely everything in our power to ensure that we've done due diligence on protecting users' security. We didn't have such a policy for either 6.x or 7.x (and I honestly don't remember what the state of the security queue was at the point of each of those releases).

2) At this point, I'm of the strong belief that we do more harm to the overall Drupal project and ecosystem by holding Drupal 8 longer versus having it release with a few bugs, even if they're nasty bugs. Among my concerns:

• Our current core contributor base is showing major strain and signs of burnout, and has been for months (years?). We can't keep expecting people to continue slogging through unassisted, and commercial investment in Drupal 8 will not happen on a wide-scale basis until 8.0.0 is released.
• https://www.drupal.org/metrics: Participation across all fronts (discussions, code contributions, etc.) on Drupal.org is either flat-lined or declining. This will only get back to comfortable numbers once 8.0.0 gets released.
• Drupal 8's feature set at this point is over 2 years old, and our competition hasn't been lying down in the meantime. For example, https://wordpress.org/plugins/json-rest-api/ is slated for WordPress core in 2015. Once Drupal 8.0.0 releases, we have tons of opportunity to make significant headway here, but not until Drupal 8.0.0 releases.
• Anecdotally, as I've traveled to various events and heard from both Drupal shops and individual site owners, new site builds are in an incredibly tricky spot right now. People don't want to build new sites on D7 and face a major upgrade challenge, and Drupal 8 isn't ready yet. Some are turning to non-Drupal solutions as a result, and if this awkward "halfway point" continues for much longer, it's going to strike an enormous blow to Drupal's adoption that will take months (years?) to recover from.

In short, there's a lot riding on Drupal 8.0.0, and it impacts the entire community and ecosystem, not just developers and site builders. We obviously want to make sure we do our best to ensure that we don't put out a crappy product that blows up in peoples' faces. But at a certain point, we will actually do more harm to Drupal by holding it until every last problem is fixed versus getting it out there and continuing to improve it after. Remember that Drupal 8.0.0 is a .0 release, and it's a well known best practice to avoid .0 releases of software if you care about stability. It's perfectly ok (and expected!) if it is not 100% perfect. It never will be.

One final point: One of the factors that played into 7.1 being 5 months from 7.0 is I kept waiting to be back to zero criticals before cutting the tag. Going back down to zero critical issues in 7.x never actually happened. And even today, almost 4 years after D7's release, there are still at least 3 known critical issues in D7: https://www.drupal.org/project/issues/search/drupal?project_issue_follow... So the above proposal could at best delay Drupal 8 by weeks/months, and at worse literally lead to us never shipping Drupal 8. :\

I think I'm with Dries. Wait until ~RC2, pick a date. And do whatever we have to to work toward that date. We need to practice working toward dates anyway if we're planning to do 6-month release cycles, and far worse than Drupal 8.0.0 shipping with any kind of horrible bug you could imagine (there's always 8.0.1, 8.0.2...) would be for Drupal 8 to be hold for weeks/months longer than it otherwise would, for all of the above reasons.

Release process

I have to agree with catch that 48 hrs is not enough, given how people contribute/report issues. They often have
one day on the week on which they do concentrated work on core, bypassing them would be problematic. On the other
hand 10 days critical free might be too much as well, hard to decide but more later.

Maybe its hard to accept, but if we don't think about majors as well, they will be criticals
for the actual sites being affected. Having time before the rushing/release will help people to still
shape the release at the same time, see burnout syndrom later.

In general I wonder whether we really need a RC has to be critical free, for a while. I really like
that betas itself already have a predictable release schedule, so will have the 8.x.y releases,
but the RCs won't. Having a schedule would help people to plan updating their sites they work on.

How can we encourage people to build sites with D8

It was layed out, that people don't start to build sites with D8, partially because we don't
ensure update support, but from my point of view much more, because people don't
really know in which state D8 is at the moment, and based upon that can't even evaluate
whether they can built a client site with D8. In that context we can place in the idea of @catch and others,
to let shops built their site in D8. We should PUSH that, maybe with a blogpost somewhere.

Burnout syndrom

As we see more and more, people start to get burned out more and more, especially by things like the beta rush,
or in the future the RC rush. If you want to get a release out (no matter whether its 8.0-RC2, 8.0.0 or 8.1.0), please don't rush.

Our current core contributor base is showing major strain and signs of burnout, and has been for months (years?). We can't keep expecting people to continue slogging through unassisted, and commercial investment in Drupal 8 will not happen on a wide-scale basis until 8.0.0 is released.

At least for me, the strain got considerably worse once Drupal 7 was released than while it was at release candidate (and I was getting paid to work with Drupal 7 for about 18 months beforehand too). I'd be interested to hear from people who are actually fixing some of the harder Drupal 8 criticals on how they feel about this.

IMHO the normal daily work is not what burns people out, but rather the enforcements, both on schedule/issue level. Given that
having these 10 days before whatever part of the release process helps a LOT to reduce the stress level. At least in theory people can take something like a "break"
for a while. Especially once the release is out, contributions on core will slow down at least for a while. Contributions on other parts of the ecosystem, like contrib, might
go up though at the same time.

We are all keen to see Drupal8 out there. The sooner the better!

But...

We need to provide time for people to test, replicate and report these issues, agree they're critical or not. And we need to be mindful that some people can only do this on weekends, and others only on weekdays, or in the evenings, or early mornings or whatever. We also need to beware the dreaded drag of timezones. Key people might need to align to chat through the issues. I think we need at least a week between each milestone of RC, final RC and the actual release.

I understand the frustration and desire to get D8 released. But I feel we'd be doing a disservice to our future selves to rush through the RC process.

It's fair to call out what I said as hyperbole. I didn't mean it that way, but my shorthand was too short. Apologies.

Here's a better way to say what I was trying to say:

Not all criticals are created equal. What I'd like to see us do in the event that a critical pops up during a 10-day window is discuss it as a group and decide whether or not it's worth restarting the clock for it.

I can respond to the rest more in detail tomorrow, but wanted to get that out quickly.

We don't exactly want to focus people on working on UI cleanup / UI text cleanup now, right?

I don't think there's another time for it, both of those would count as 'prioritized changes' during beta.

String/translation freeze is probably when the first release candidate is cut yes.

So there is not much contesting those things on this issue, looks like the release date is more interesting. Should we consider this part an agreed policy then? Looking at what happened in Drupal 7, based on https://localize.drupal.org/node/640 and https://localize.drupal.org/node/712 it is hard to tell when/if there was a string freeze. We released Drupal 7 a year after. I'd like to keep translators up to date on what they should expect about translatability so they don't translate too soon but also they don't strt so late that they would need to rush.

Following #25 and #26, we discussed this a bit more with @Dries, @catch, @webchick, @alexpott, @effulgentsia, and myself. There are two things we need to take into account when we decide to release 8.0.0:

1. The release date should be scheduled in advance, with several weeks for everyone in the community (from D6 site owners to the Drupal Association staff) to plan for the release.
2. The release date needs to be reliable--once we officially announce it, we don't change it--so we need to be confident that we can actually release something fit for production. "Fit for production" doesn't mean there's never another critical bug--of course there will be--just that critical bugs we do discover can be addressed reliably.

To try to address both these points, @catch and I drafted this for the release cycle page, based on those earlier discussions:

Drupal 8 (like any software) will continue to have critical bugs found during the release candidate phase and after release. What is important for site owners is that the 8.0.0 release is stable enough that occasional new critical bugs can be resolved quickly, instead of adding to an extensive backlog of (as-yet undiscovered) issues that will cumulatively take many weeks to resolve. For core contributors, it is important that 8.0.0 marks the point at which issues which have been deferred to 8.0.1 can be worked on again, since this may include several hundred major bugs that could seriously affect sites in production.

To this end, the branch maintainers will monitor the rate of incoming critical bugs weekly during the release candidate phase (beginning before the first release candidate). To allow for a regular release schedule with incremental improvements from the previous release, we may tag release candidates with open critical issues as long as they are not regressions from the first release candidate. We will schedule an official release date for 8.0.0 a minimum of three weeks in the future when we are confident that the rate of incoming bugs has slowed enough to ensure a stable, timely release.

I'll incorporate this into the summary in a bit, but wanted to post this for everyone's review.

Looks great to me. A couple questions:

as long as they are not regressions from the first release candidate

Should this be prior RC instead of first RC?

a minimum of three weeks

Is that long enough? Sure, minimum means we can make it longer, but if the purpose of giving a time minimum in this doc at all is to satisfy concerns of the various people who need that information, does 3 weeks accomplish that?

when we are confident that the rate of incoming bugs

Should this be incoming critical bugs?

however, releasing with zero critical bugs is the single biggest thing we could do to ensure we can quickly resolve further critical bugs, yet we seem to be explicitly rejecting that.

There is nothing in this that says we're going to deliberately release with critical bugs. We have to get to 0 critical bugs before we create a release candidate, so we won't even be discussing a date until that happens. It's subsequently uncovered bugs that we're trying to address.

@beejeebus, we dropped the explicit, possibly endlessly looping 10-day clock thing in favor of paying attention to the rate of incoming critical issues overall. So if we're having 5 new critical issues per week around the first RC, we're certainly not picking a date until that settles down. On the other hand, if by some miracle we have only had 1-2 criticals incoming in the month before the first RC, and then 1 additional one between the first and second RCs, then we'd probably reasonably feel confident enough to set the date. And then starts the three (but probably more like 4-6) week countdown.

(Edited many times.) ;)

Re #31.1, are you saying something like:
- RC1: tagged with 0 known criticals.
- RC2: tagged with 0 known regressions relative to RC1.
- But, 2 days later we discover RC2 actually has a regression.
- 12 days later, HEAD has fixed some critical issues discovered with RC1 and RC2, but has not yet fixed the regression.
- Do we tag an RC3 or hold it up on fixing that regression?

So long as HEAD isn't any worse than RC2, I don't see why we shouldn't tag the RC3. If people are already on RC2, there's no reason for them not to update to RC3. If people stuck to RC1 because before they were about to update to RC2 they had already learned about the regression, then they can continue to stay on RC1 so long as RC3's release notes mention that the regression discovered in RC2 is not yet fixed.

Or, does tagging RC3 without having fixed the regression make it harder to then fix the regression, because now there's 2 RCs out in the wild with a regression relative to RC1. I'm not clear on why that would matter, but if the nature of the regression is that it does matter, then yes, in that case, it would make sense to hold up the RC3.

Meanwhile, I don't get what "no regression relative to RC1" accomplishes. Consider the above scenario but with each RC incremented by one. In other words, RC3 has a regression relative to RC2, but not to RC1. And then we need to make the call on whether to tag RC4 or not. RC1 is irrelevant at that point. So the most conservative thing would be to say "no known regressions relative to any RC", but I don't think we need to be that conservative with all regressions, only nasty ones that would complicate future upgrade paths.

There are more thoughts swirling in my head , one of the issues (irrelevant which, people know) mostly just sparkles writing them down.

1. One of the fundamentals of Drupal were hooks. Instead of doing a requirements-pros-cons analysis based on what Drupal, Symfony and other frameworks did we have not replaced but added Symfony's event system which in every possible way is the exact opposite of hooks: explicit vs implicit, functions vs method, priorities vs weights. It also turned out that the system didn't scale to Drupal's needs so we have overwritten/extended Symfony's relevant parts. More would be needed.
2. One of the fundamentals of Drupal is handling incoming and outgoing links/paths/routing. Instead of doing a requirements-pros-cons analysis based on what Drupal, Symfony and other frameworks are doing we have added Symfony CMF's routing system. When it turned out it (immediately) doesn't scale to Drupal's needs we have overwritten/extended Symfony's relevant parts. However, this was not enough and instead of doing more of this we have decided to solve the performance issues by storing and make routes our central API despite neither incoming nor outgoing links are routes.

Now, let's talk of release. There are two routes ahead: PHP 5 and PHP 6. PHP 6 was poised to be a revolution, had books printed then stalled and never was released. PHP 5.0 was a horrible release, PHP 5.0.5 broke things so badly several people didn't touch PHP 5 until GoPHP years and years later made them. PHP 5.2 was a pleasant release.

I do not think the community can fix the mess created in any reasonable time frame. klausi had the right idea: pick a date, I recommend two weeks after DrupalCon Los Angeles and release Drupal 8.0.0. Deadline makes things happen. We know that. We can rally people much better around a big days and minutes countdown visible on every page than an obscure critical countdown marker that can not reach zero.

+1 for the "pick a date" idea.
My personal and non-objective feeling has been that the community (contributor, shop, client) enthusiasm has been severerely drained,
and the ever-shifting release date estimations are a large factor in that.

I created a Drupal 8 translation status page at https://localize.drupal.org/translate/drupal8 and posted this info:

Is it ready for translation?

Drupal 8 is still in development and there are still some interface changes expected. As per the beta changes policy interface string are unfrozen and user experience improvements are prioritized. However, we are getting close to releasing beta versions with support for the upgrade path and that means more sites will start to use pre-release versions of Drupal 8. This helps find bugs and we would love the multilingual system to be thoroughly tested as well. We need translations for that to happen. We also need translators to look at source strings, so they submit issues found in them.

Strings will likely be frozen with the first release candidate (which is cut when there are no more critical issues against Drupal 8). That release candidate may become a release as early as a couple weeks after, so starting translation at that time would be too late to be ready for the release.

It would be great to get confirmation that its correct, before I promote it more widely. I did not use the exact 10 day after the RC1 because that seems to be in discussion, so I put in a more relaxed "couple weeks", but we can of course update that or anything else.

Got confirmation from @catch over IRC that that text is correct. Posted https://localize.drupal.org/node/63758.

Once the 8.0.0 release window is set, if there are not unexpected critical issues open, we'll allow code-style cleanups to be committed during this period. These can be very disruptive to other patches but have an extremely low chance of introducing regressions.

Just a note, I think this understates the chance of coding standards fixes causing regressions. The patches tend to be easy to create but challenging to review, and things like renaming internal variables/protected properties or whatnot could actually easily break things. Now, I guess they're unlikely to introduce critical regressions, but nonetheless. I also think this should only take effect if we have testbot support for coding standards by that point, and we'd managed the issues in a controlled way (scoped cleanup for one rule, plus test for said rule). (Outside of docs that is. We can always make docs better.) It goes without saying, but I'll just say it for clarity: these also can't be any cleanups that introduce BC breaks (e.g. renaming classes or public methods).

To close this issue, I guess we need:

• Helpful illustrations
• Signoffs from all the branch maintainers
• Updates to relevant handbook documentation

I've started doodling some diagrams.

Trying to make it diagrammable...

• We'll almost immediately tag and release a 'final' beta once zero critical issues remain.
• The first release candidate will not be tagged until we've successfully stayed at 0 critical issues for at least 72 hours, to give the last patches time to settle in.

Do we actually need to do that? Why not just start a 72-hour code freeze for said patch marination, and then tag the RC once it's marinated? Seems tagging a release with a life expectancy of 72h is overhead/confusion/mixed messaging.

If a release candidate goes out with a known critical issue, it will be named RC1b instead of RC2, but this could also just be tracked internally and mentioned in the release notes.

Does our infrastructure support this?

Draft diagram of the RC phase based only on the issue summary: https://docs.google.com/a/acquia.com/drawings/d/121Rx3G6l7deGSadOP5mVJZj...

I started to make an 8.0.0 -> 8.1.0 diagram but the updated summary doesn't look like what we discussed; it's got conditionals about 10 days? I think it's more important to keep a regular month patch release schedule and six-month minor release schedule, for predictability. Other software projects don't change their minor release schedules based on outstanding issues, do they? Barring something nuclear-level like a highly critical SA or data-destroying bug, I think we should keep to the strict release schedule. Critical issues should trigger feature freeze for minor versions though (which is not mentioned in the summary).

I made the diagram based on the current summary, but the current summary is also more conservative than this from #29 (which had consensus at the time):

when we are confident that the rate of incoming bugs has slowed enough to ensure a stable, timely release.

If we had only one critical bug in 2 weeks after we'd already gotten to 0 critical issues, and there had furthermore been only a low rate of incoming criticals leading up to the first RC, I would still be comfortable setting a release date.

We currently have a monthly-ish schedule for betas. We could just make the next beta release an RC instead. Then people going release to release still have a predictable schedule.

That could make sense, but what if the last critical is fixed (say) 5 days after the previous beta? Would we stay in a full code freeze for 3+ weeks with no stable for folks to test? Maybe we could wait for the next "half beta" date if it's in the first half of the month? (In keeping with the 2-week RC schedule.)

So here is an alternate diagram, based on the earlier consensus from #29 and some related discussion @catch, @webchick, @effulgentsia, and I had over the past two weeks:
https://docs.google.com/a/acquia.com/drawings/d/1tELtDLgCIoLlMlKvFYaDYAM...

Changes from the previous diagram:

1. Instead of a fixed 72h freeze between reaching zero criticals and the first RC, we release the first RC on the next D6/7 release window date after we get to 0 criticals (either the bugfix window on the first Wednesday, or the security release window on the third Wednesday).
   • The primary reason for this change is that we need to synch up the D8 release schedule for future core SAs.
   • It also ensures a predictable release schedule, which we've learned is the most important factor for many audiences.
   • If the "next" D7 release window were the the next day or something, I imagine we'd use the following one instead.
2. It removes the requirement for a "full" RC to pass with no additional criticals; instead, branch maintainers use their discretion based on the rate of incoming criticals and the current count during the RC phase.
   • It's still required to get to zero criticals before the first RC, and no release date will be set before this happens.
   • Conversely, even if we get to zero criticals again, no release date will be set if the rate of incoming criticals is unmanageably high.
3. The net result of (1) and (2) is that there is still a minimum of one month between reaching zero criticals and the 8.0.0 release, but it may also be significantly longer if the rate of incoming criticals becomes (or remains) too high.
4. It removes the "RC 2b" naming since that would probably be confusing.
   • Known criticals will still be documented prominently in the release notes for each RC.
5. Finally, it adds a more realistic spike of criticals after the first RC for illustration.

(moving to previous comment)

FWIW, #51 looks good to me.

Per discussion with @webchick (as well as earlier discussion with @catch). Clarifying that it's not only the number of incoming criticals that affect when we set a release date, it's also their nature (i.e. what kinds of criticals they are). Some critical things are an easy hotfix; others have much bigger implications. So we will be taking that into account as well.

Ok, so if I'm reading #51 properly (using totally arbitrary and made up dates for the purpose of clarity) this is probably the "best-case scenario":

1. June 17, 2015 (Wednesday): D8 release window happens. We still have 3 outstanding critical issues. Since 3 is greater than 0, we release a beta.
2. June 23, 2015 (following Tuesday): Holy crap, we hit zero critical issues!! But nothing happens until...
3. July 1, 2015 (first Wednesday of the month): Earliest D6/D7 release window. If the critical count stayed at zero, we roll RC 1, to wild acclaim. From this point on, only critical D8 issues are committed.
4. July 2, 2015 (a few hours later): Darn it, people actually tested the RC and now 10 critical issues come banging down our door. We all share a good group cry, then get to work.
5. July 15, 2015 (third Wednesday of the month): Next D6/D7 release window. We managed to fix 7 of those critical issues in the meantime, but we're not at zero yet. Nevertheless, we roll a RC2 so at least people can incorporate the bug fixes we did manage to do. Release notes mention both those fixed and outstanding criticals.
6. July 16, 2015 (a few hours later): Darn, another new critical. But not a flood of them. And this one is a really dumb regression that was simply introduced because of lack of test coverage while we were fixing one of the others. It's fixed within a couple of hours.
7. July 20, 2015 (the following Monday): OK, we are back down to zero again. Fingers crossed...
8. July 23, 2015 (a couple of days later): Still no new criticals. The only new critical there has been since RC2 was a pretty simple one; we're no longer catching enormous data model omissions or what have you like we did in RC1. The core committers meet to discuss setting a release date. They set it for 4 weeks in the future, to be safe, and announce it as August 19, 2015, very widely. (this is the D6/D7 release window after the next one)
9. August 5, 2015 (first Wednesday of the month) Next D6/D7 release window. Here comes RC3!
10. August 6, 2015 (a few hours later) Nuts, another critical. This one's a bit nasty, but it's fixed in 3 days.
11. August 18, 2015 (day before release) No new criticals. We are good to go!
12. August 19, 2015 Drupal 8.0.0 released, to wild fanfare and international parties everywhere! YAYYYYYY!!!
13. August 20, 2015 (a few hours later) Damn it, another 10 critical issues. :P (Make no mistake; this will happen, no matter how careful we are. :P)

(BY THE WAY, DID I MENTION THESE ARE TOTALLY ARBITRARY AND MADE UP DATES BECAUSE THEY ARE! :P)

Conversely, in a worst-case scenario, we keep finding really nasty bugs and push release date out for months and months. Or, we find a horrible security problem the day before we plan to release, and have to release anyway. Or etc.

Some feedback:

• On the one hand, I really like synchronizing RCs on the D6/D7 release windows. This both guarantees us a window every ~2 weeks and also makes things more predictable. In fact, it might be good to start syncing up D8's beta schedule and D6/7's release schedule basically now (most likely security schedule since that's later in the month [third Wednesday], which is when these tend to come out now). That way: a) there's no new timing tricks to learn when this policy starts, b) we will eventually be at zero public security vulnerabilities and would presumably like to stay that way, c) it's good practice for the "real deal." :)
• On the other, synchronizing to those windows introduces a lot of latency into things. In the best-case scenario, we go for about 1.5 months (July 1 -> August 19) without committing a single non-critical issue. Two things are going to happen: 1) The RTBC queue will grow astronomically high, which means building up a large "technical debt" of sorts to deal with (not to mention the "morale debt" that goes along with a high RTBC queue) 2) we'll end up hemorrhaging core contributors by the truckload (relatively few contributors can help solve criticals versus those who can work on everything else) and we will just have to hope they come back when things are moving again. Most of them have contrib modules to port, and/or vacations they should be taking, so maybe this is fine, but IMO it's a pretty big risk. OTOH, accepting this risk is seemingly the only thing that stops us from a never-ending-resettings-clock so maybe that's an acceptable risk.
• Regarding the "rate" of incoming criticals, to me it's not so much the rate (though it's that, too), as it is the severity (there are "grades" of criticals). Looking at criticals that were just fixed in the past week, for example, #2342045: Standard views base fields need to use same rendering as Field UI fields, for formatting, access checking, and translation consistency is a "woah, re-think everything you once knew" kind of critical. Versus #2453351: Maintenance mode message ends up in page cache, served endlessly is a head-slapping "D'oh, we should have had test coverage for that." Neither are problems we can ship D8 without them being fixed. If we have 3 of the latter coming in per week, my feeling would still be "eff it, ship it." But if we have even 1 of the former coming in per week, that's a much more severe thing. (Shared this feedback with Jess and she's updating the diagram.)
• This process basically incentivizes a lot of people not to test RCs. The more testing we have, the more critical issues we find. Which is of course what we want. But if we put our heads in the sand, everything appears great, so for those companies/individuals motivated for a D8 release sooner than later (which is a lot of them), it actually makes more logical sense for them not to test, or at least not to report what they find at the proper priority. :\ So we'll need to make sure we're on top of triage much more than normal to catch things.

In the end, I think on the whole I'm +1 here, but would love to thinker on it some more.

So the one mitigation to #56 is regarding:

only critical D8 issues are committed.

I think the asterisk on the chart is important here for keeping people engaged -- committing non-disruptive majors, docs improvements, etc. Still, 8.0.0 to 8.0.1 will end up being a lot of RTBC catch-up.

Updated the summary based on the most recent proposal. The one part I didn't update is the part about 8.1.x, which we haven't discussed and I'm not sure about, but I also think that doesn't need to block the more urgent RC policy.

I moved the discussion of 8.1.x to its own issue, since it shouldn't block us finalizing the RC phase info, but does need to be discussed in more detail in the coming months: #2455081: [policy, no patch] 8.1.x release schedule

I really like the predictable nature of the 2 week release candidates - this means that anyone building a site can easily plan when to move to the next RC. And releasing RC's with known and announced criticals is a good idea because it is likely that the previous RC will have the critical and therefore people can thinking about how mitigate its effects until the bugfix lands.

I'm also in favour of announcing a release date and sticking to it.

The plan looks good to me.

Agreed about the major triage. My hope is to rally some folks to start work on that around DrupalCon LA.

While I was involved with offline discussions around this, I wanted to publicly state my support for this proposal and sign off on it. As long we're good at separating release blocking bugs from non-release blocking bugs, this approach should work well. The predictable release candidate schedule will be helpful for site builders and will give us confidence in the stability of 8.0.0. I'm also in favor of announcing a release date and sticking to it.

PS: Angie's example in #56 was very helpful. If you haven't read that, I recommend you do.

I've updated the release cycle page to incorporate this information at:
https://www.drupal.org/core/release-cycle#rc
I also added a stub section about 8.0.0 and semver while I was at it.

Thanks everyone for all the feedback on this discussion!