[meta] The Drupal 8.0.0-rc1 Release Checklist

Added meta task for SQLite under the "Run automated tests against all supported PHP/database versions" item because that's where most of that work is being done.

#2267715: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1 could probably move under this one as well - by definition there's nothing can be done in the core queue to resolve those.

Personally I think #2116841: [policy] Decide what the Drupal Public API should be and how to manage it belongs on this list.
We want to make sure that we have enough flexibility in 8.1, 8.2 by flagging what constitutes our API and our BC promise

#9++

#2116841: [policy] Decide what the Drupal Public API should be and how to manage it should be a "revisit before release candidate" like our 8.1.x policy. I've so tagged it.

@catch. @alexpott, @effulgentsia, and I all agreed with the approach @webchick recommended for this issues, so marking as a triaged critical.

i believe #9 should point to #2470679: [meta] Identify necessary performance optimizations for common profiling scenarios?

Good call, but I think #2497185: [no patch] Create standardized core profiling scenarios and start tracking metrics for them is even more specific, so updated #9 to link to that.

Raised that one to critical, since it's a blocker for performing that checklist item, but keeping the checklist item too, since the state of HEAD just prior to tagging the RC is what will need to get re-profiled to verify there aren't last-minute surprise regressions.

Added references to #2508231: Raise minimum required version of PHP to 5.5.9 and #2508567: DrupalCI SQLite random failures which are currently the top priorities for this.

I'm at the Drupal GovCon sprint, and working on the issue.

@xjm, we still have #2524426: [meta] DrupalCI pgsql Random exceptions, fails, testbot issues. I spend hours and hours to trace this down with no luck, guess we need an installer guru here :) I ran the legacy (drupalCI) bot and it shows not a single random exception, just with on current drupalCI...

Can I add something to the checklist? #2380651: Remove or rename Classy's layout.css file and adjust tests

It would be silly if we release with the empty layout.css file in Classy. I've been waiting until we got a more appropriate CSS file moved over, like one of the system files, but if we don't we can still latch on to one of the ones there now for testing.

I didn't want to do it yet, because work is being done to move files over (Lewis mentioned sprints on that for this weekend,) but if that doesn't happen this is still an easy fix.

@davidhernandez
Would it be an API break if we remove that later, if its empty? In general I don't see why you would stop a release from happening because of this file ...

@dawehner, we would not stop a release on it. I just don't want to forget to do it, and I think we should remove it before release. It currently being there is dumb, because every theme relying on Classy has to purposefully remove it with stylesheets-remove, or otherwise wonder why some empty CSS file keeps getting linked. I could remove it now, and change it again later, or just sneak it in late. (how do I do an emoticon for a shoulder shrug?)

Ok, fair enough.

This may or may not be the place to raise this issue..

I would like to get testbot to automate this test - but can't see how.

Since January we have had a syntax like error in out main composer.json file and it has gone undetected.
( It could also be considered a unexpected value error" )

#2545430: Remove "UnexpectedValueException" from composer.json

In the d.o spirit I would help out on an issue to automate this as a pre-release check.

Should we consider adding a follow-up to #1392754: Comply with new documentation standards for @file for namespaced class files to the list? Should be a relative quick follow-up as I count about 40 files with @file docblocks out of spec after that issue was fixed.

Its pretty clear that the we need to strangle Drupal 8 in order to get it released. The pace of incoming criticals is fast enough that we need to cut as much scope as humanly possible in order to be momentarily releasable. In that spirit, here is the scope that I propose to cut.

1. Determine the definition of internal vs. external API ... If we can get this done before release, thats ideal. But I'm not willing to hold a release (or worse, an RC) for it. Implementers will have a little less certainty - sad but tolerable.
2. Ensure that there are no critical issues blocking the Drupal 6 =>Drupal 7 upgrade path ... I cant fathom why we would block D8 on this. This is D7's problem. We are shipping with a migration path directly from D6 to D8. And even if we decide to drop migrate from 8.0.0, this is still D7's problem.
3. Ensure there are no "critical" or "highly critical" private security issues against D6/D7 core ... These are currently private, and will remain private after 8.0.0. I even think that it is tolerable to release 8.0.0 with private security issues in D8. We have had critical security issues against D7 for its whole lifetime and life goes on.
4. Revisit before release and especially #2212151: Document/test updating active configuration based on API changes (i.e. plugins) ... The kind soul who needs these docs can post to the Handbook.
5. #2467925: [plan] Remove blockers to the "minimum viable" state of DrupalCI to ship Drupal 8 RC1 ... This looks massive. I submit that our current test bot is good enough for 8.0.0.

1.The problem is not implementers, it's every core patch that is submitted/lands in every minor version. That issue is nearly RTBC as far as I'm concerned, I'd even paste the current issue summary straight into a handbook page now and call it good-enough-for-RC. Even if it wasn't, a few more hours (at most) discussion on that is infinitely preferable to thousands of hours trying to sort this out patch by patch because we failed to do some basic work. Also RC is the point where we absolutely stop committing patches that would fall under this (and anything remotely-risky looking that doesn't), so making it clear what's going to happen to them (8.0.x, 8.1.x, 9.x, whether they need to add BC before they can be committed etc.) helps people working on those patches now to see what's up next. We cut the first beta before #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase? was resolved and that cost me personally tens of hours in talking to people about their issues (including at DrupalCon Amsterdam itself) - which is time I'd rather spend doing almost anything else.

2. The moment 8.0.0 comes out there is a three month count down to us dropping support from 6.x. That is not Drupal 7's problem, and it's not mentioned in your comment. The one issue on that item is RTBC, just waiting for a 7.x release. Also

We are shipping with a migration path directly from D6 to D8.

Not yet we're not. You can't even run a migration with core yet?

3. This was agreed with the security team to mitigate the maintenance impact of extending Drupal 6 support 3 months longer than originally planned. See #2136029: Decide if and how to extend D6 security support 3 months past an 8.0.0 release. Do you want to block release on re-hashing that 137 comment discussion?
I'd rather spend the energy fixing the critical/highly critical issues that come up through the security bug bounty that's still running against 8.x

4. This list is being cut down rapidly, but in the process of cutting it down we have found a few things we really did want to revisit. Anything we decide we don't want to, or has been revisited enough, has just been untagged.

5. #2467925: [plan] Remove blockers to the "minimum viable" state of DrupalCI to ship Drupal 8 RC1 "This looks massive" - except there is an issue summary with three non-fixed issues? What exactly is massive?

So I don't see what trying to descope quite simple items from this helps apart from re-opening long-closed discussions that took weeks to resolve between multiple people.

We are shipping with a migration path directly from D6 to D8.

Not yet we're not. You can't even run a migration with core yet?

You could do that 9 months ago from the command line :) - https://codedrop.com.au/blog/video-drupal-6-drupal-8-migration

That video is using drush.

Yeah I said from the command line. The UI is working and should be coming soon!

Right but the drush requirement means you "can't run a migration with core yet".

The checklist item is about making sure that 6.x sites can get to either 7.x or 8.x before 6.x support is dropped - which means via the UI since we still don't require command line at all (let alone drush) to run a Drupal site.

If either a fully supported migrate UI with 6-8 is in 8.0.0, or there are no critical bugs in the 6-7 upgrade path then that checklist item is done.

Right now the 6-7 upgrade path has one RTBC critical issue, migrate has 14 critical issues. If both are done by the time we release 8.0.0, then great, but if not then either one satisfies the 'let people get off 6.x at all' requirement, which is really the minimum we can do given there are at least 125k installs out there.

Removing the 6-7 upgrade path from the checklist (which is only an and/or with migrate) we'd then be 100% blocking the 8.x release candidate on migrate, which is completely counter-productive to reducing scope on what we have to do to get the release out.

Per https://www.drupal.org/node/2559877#comment-10274677 should we open a manually test all the things issue?

I finished writing a browser testing plan in #2152519: [meta] Make sure Drupal 8 looks good and works right on browsers (both mobile+desktop) based on the brainstorming. Feel free to provide feedback or maybe ready to start testing?

If you want some really painful feedback, I'm also certainly going to be on the Edge network in a car somewhere tomorrow.

"This person tried to use Drupal 8 with virtually no Internet connection: you won't believe what happened next!"

It may worth creating a separate issue, but I know that saucelabs provides an opensource plan (https://saucelabs.com/opensauce/) for testing open source projects across a range of browsers. It may be beneficial to create a script that will screenshot/record the supported IE versions, and Chrome/Firefox across Windows, Mac, Linux and even mobile devices.

This can even test different resolutions to check that there are no obvious visual glitches.

Undoing the change in #62. We actually need to look at closed (fixed) too.

OH I get what you mean

> Ensure that there are no critical issues blocking the Drupal 6 =>Drupal 7 upgrade path (critical D7 issues with the "D7 upgrade path" tag).

I am not 100% sure why this should block RC1 or even a release. Aren't we supporting D6 for three months past release? If we do then we can commit these in a minor during those three months.

I am not 100% sure why this should block RC1 or even a release. Aren't we supporting D6 for three months past release? If we do then we can commit these in a minor during those three months.

The last time I worked on a major version site upgrade, it took longer than three months to complete from start to finish.

Additionally there's one issue, which is RTBC, against Drupal 7, which would close this item at #1260938: d6 to d7 update fails on file duplicates '#7061 Integrity constraint violation'. It has been RTBC for about three months or so. What's to say it won't stay at RTBC for a further three months past release if we punt on it now?

Once we tag 8.0.0 we start an immediate, fixed, countdown to 6.x sites being unsupported. Given there are still over 100k sites on Drupal 6 reporting back to Drupal.org, I think closing the upgrade path criticals prior to starting that countdown is pretty minimal to be honest.

Critical bugs in the Drupal 7 upgrade path from Drupal 6 could and should have blocked the opening of the 8.x branch rather than being punted all the way to the tagging of the first release candidate. It's unfortunately too late to undo that, so here we are.

I don't see 'Remove @deprecated stuff' anywhere.

So to clarify some positions: catch feels like an RC1 is a candidate for release. It's something we could theoretically release but for testing purposes we don't.

Others feel like RC1 is just the next step after beta where we become insanely picky on what we commit to gear for release but we know it's not a release anyways so why treat it as a release?

This second, more pragmatic position is supported by the past: we had an API freeze after that an API completion phase (where theoretically APIs were supposed to change less) and we are now a beta phase (now really we don't want to change APIs). AFAIK we have been breaking APIs up to the last beta. So it seems like a more pragmatic approach were taken in the past.

#1031122: postgres changeField() is unable to convert to bytea column type correctly is a postgres issue only, and we have no automated testing of postgres on 7.x. So for me at least that's not remotely relevant as a release blocking 6-7 upgrade path issue. We can ship 8.x with actual tested support for new sites on postgres (finally!), but nothing resembling that is going to happen for postgres on older releases (short of a miracle).

Also that issue has shown that it's not possible to update from a serialized field stored in TEXT to bytea (because you can't store serialized data in TEXT fields on postgres reliably in the first place) so effectively there can never be a 100% successful upgrade path from 6.x-7.x on postgres (given upgrading the {variables}.value column was how that bug was found). There's some value to backporting that patch to 7.x, but I don't think it will fix the original problem that was reported unfortunately.

...and neither does telling 3,118 contributors who worked their asses off on D8 (assuming we get to 0 criticals by Sep 14th or whatever), "Sorry, even though we've at last met the goal of 0 critical issues, we're not putting out an RC because D6 and Postgres"

There are 128,000 sites on Drupal 6.

Are we going to say "Sorry, even though there are 128,000 sites on Drupal 6 and we never fixed the upgrade path from Drupal 6 to Drupal 7 we're going to put out an RC anyway. But hey there's a patch which you can all individually apply 128,000 times instead of us doing it once if you want to get started."?

People are already popping up around the place questioning the 3 month support window with migrate being marked as experimental, at least 'there is an upgrade path to Drupal 7 with no critical bugs' and 'there are no known critical security issues' gives us a reasonably clean slate.

This second, more pragmatic position is supported by the past: we had an API freeze after that an API completion phase (where theoretically APIs were supposed to change less) and we are now a beta phase (now really we don't want to change APIs). AFAIK we have been breaking APIs up to the last beta. So it seems like a more pragmatic approach were taken in the past.

I don't think the API freeze was pragmatic, it was an over-optimistic arbitrary marker that turned out to be completely unworkable. In fact it was the opposite of pragmatic calling that date. I think it actually cost us about a year's extra release time because people stopped working on release blocking work that had supposedly been cut off, which then had to be revived again as it got rediscovered in the run up to beta and later.

Similarly calling the beta with both URL generation and having crammed in SafeMarkup was over-optimistic as well. Fortunately the beta-policy meant that we (at least 99% of the time) did not arbitrarily shut down release blocking work and actually focused efforts towards it.

@chx in terms of core code I think we should aim for the first RC being an actual release candidate in that we don't have hidden release-blocking core changes to make when it's tagged. We can't help things we don't know about yet, but we can help the things we do. Similarly we really, genuinely, do want to slow down the commit rate during release candidate (to only criticals, low-disruption majors and possibly docs/coding standards) and that needs to be a realistic proposition when we cut it then.

This does not apply to the 6-7 upgrade path since there's no 8.x change to be made there though. That's really about giving 6.x sites a decent shake to get off that version if they want to. People generally agree 3 months is pretty short for 6.x support (good reasons for it to be short, but it is short), so at least being able to use a dev release of 7.x to update with during release candidate of Drupal 8 gives them a bit more of a chance to get upgraded compared to 'apply this patch from this 200-comment-long issue'. Also given the patch has been RTBC for three months it's really not going to hold things up that much if at all so I don't know why people are so keen to punt on it rather than just get it in.

I support catch's position here. if not now, when? i also agree about the point of "release candidate" being not just "beta by another name".

OK, wow - I learned about this brouhaha very recently, and last week said I would commit #1260938: d6 to d7 update fails on file duplicates '#7061 Integrity constraint violation' this week which I've now done :)

I think there was some miscommunication here since we actually discussed this a couple months ago (see #2030501-48: [meta] Ensure that Drupal 6 sites have a functional upgrade path to either Drupal 7 or 8 before Drupal 6 loses security support and surrounding comments) and concluded at the time that the D6->D7 upgrade path was in good shape for Drupal 8's purposes (barring any newly-found problems, of course) and that that issue could stay RTBC and proceed on the normal Drupal 7 timeline. Of course the idea was always that it was necessary to get it into the next D7 bug/feature release, which it will be. It was RTBC for 2 months (not 3+ months) which is a pretty normal amount of time, and during that time two people came to the issue intending to test it on a real Drupal 6-to-7 upgrade. Neither of those panned out yet, but it was certainly worth waiting a bit for.

I guess some people were counting on this being in a September 2 release, but that was always a tentative date for the next D7 release and it didn't happen - I'm sorry if I missed that this was an important date to people. However, based on https://www.drupal.org/core/dev-cycle#rc the earliest possible release date for Drupal 8.0.0 is October 7 anyway, so even in that scenario the D7 release that has this fix would be able to come out on the same day as 8.0.0, which seems OK to me - I don't think the revised D7 timeline is blocking anything.

Just to clarify, I have never been offered D8 Accelerate funds to maintain Drupal 7. To the best of my understanding, this is not something the D.A. wants to fund right now. That is their decision (and they did name it "D8 Accelerate"....) It was suggested to me recently that I could apply for D8 Accelerate funds to do specific things related to Drupal 8's release (for example, commit the above patch to Drupal 7) and I would presumably get them, but doing a final review and committing it is not something that takes a lot of time, so it's really not worth it. (I put in a lot of time on that issue already, but it was all a few months ago.) I have accepted a (very) small amount of D8 Accelerate funding in the past for an actual Drupal 8 issue, but for several reasons I'm not likely to apply for it in the near future, the main one being that I already have enough paid Drupal work on my plate...

Also, for the record, I do think critical problems with Drupal 7 PostgreSQL should be considered critical D7 bugs. But I can accept that a D6-to-D7 upgrade issue that only affects PostgreSQL shouldn't be, since that requires that you ran your Drupal 6 site on PostgreSQL too, and in Drupal 6 it was definitely way less supported (without the full-fledged database API, etc - it was mostly just up to module maintainers to make sure their queries were PostgreSQL-compatible). So in practice anything upgrade-related in #1031122: postgres changeField() is unable to convert to bytea column type correctly should only affect Drupal 6 sites that are already used to hacking their way through things...

I have a new issue suggestion for your list:
"A plain-english guide to the outstanding major D8 bugs".

From that IS:

"D8 RC1 will attract major attention, and we want it to. Many new users will try out D8, and many will spend a lot of time site-building on it, even if they are warned of the risks of doing so.

There are currently many major bugs in D8. Bits of the UI that do not work as advertised, etc.

In theory the issue queues document all these. But to anyone who is not already a D8 expert, they are difficult to penetrate, and impossible to survey. Imagine you wanted to brief a sitebuilder colleague as to what bits of D8 they should not expect to use at the moment. How would you even begin to do that?

Enormous amounts of user frustration - and damage (even though unfair) to Drupal's reputation - could be alleviated by a regularly updated "Plain english guide to outstanding major D8 bugs", which could be prominently linked to from D8 release notices etc."

(Updating link.)

@xjm
Oh no, we want to revisit really every issue? ^^

@dawehner we said we would when we introduced the tag (as a way to not have non-actionable critical issues), but we've been quietly doing that for months now, and there's only a few left. Also sometimes revisiting is "Do we want to revisit this? Err no we don't, untag." but equally it's thrown up some things which needed to be revived too.

Oh I see, had assumed it was just updated to show closed.

Committers have discussed all the "revisit before release candidate issues", and aside from two outstanding followup tasks still in progress, that list is clear! Yay!

Going forward, anything that needs to be considered before RC to be explicitly marked critical so that it gets assessed as soon as possible (keep in mind the definition of critical priority), or added to the "at time of RC" list if it doesn't make sense to address before then.

Hooray!

Yay!