[meta] Drupal.org (websites/infra) blockers to Drupal 8.0.0, 8.1.0, etc.

#2267715: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1 just got fixed, so there are no more RC1 blockers, but also no reason the DA can't be working on these issues now, so bumping this one to active.

Just making sure #2268449: Run contrib module branch tests against both dev and latest stable core branches is on everyone's radar. Catch brought it up again today. We need this to open the 8.1.x branch and while we haven't decided exactly when we want to do this, chances are we will want to do it ASAP after RC1.

#2268449: Run contrib module branch tests against both dev and latest stable core branches wasn't in the list for some reason, adding it.

Removing the subtree split issue from the "nice to haves" (to "uncategorized" instead) since it really doesn't have consensus yet.

During the meeting, we also identified that the module download page for 8.x compatibility is way confusing. If you search for 8.x full project compatibility:
https://www.drupal.org/project/project_module?f%5B0%5D=&f%5B1%5D=&f%5B2%...
The first page of results includes both Entity Reference and Views, which is very confusing for website users since both these modules are in Drupal 8 core and do not need to be installed in D8. Both have 8.x branches from earlier development (before they were in core), but no supported, recommended, nor snapshot releases. Perhaps the listing should only display modules that have at least one of these three things for the selected version? Not sure what project to file that under. It's not a hard blocker for D8 release, but it is going to come up as we encourage people to use that listing in upcoming announcements.

I opened #2605248: Sort by usage of major version when /download is filtered by Drupal version for the confusing download page.

#1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib) is now in. It is not integrated to localize.drupal.org, however, we have #2607956: Server support for Drupal 8 shipped config across projects (contributed modules) for that. Added that to the issue summary. That was basically split from #1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib), so we can move in pieces :)

#2580293: Patch having test with "PHP Fatal error" is marked as PASSED is also pretty severe and should potentially be on this list.

I moved #2268449: Run contrib module branch tests against both dev and latest stable core branches down to the correct header (I think).

Per conversation with @gáborhojtsy - the work in #2607956: Server support for Drupal 8 shipped config across projects (contributed modules) does NOT block release - but can have final testing and deployment as a follow up to complete the support for contrib translatability.

Adding #66484: Allow issues to be filed against multiple versions/branches..

And #1171958: Allow files to be assigned to branch(es)/version(s) and thus tested against it.

Another problem we have currently with 8.1.x development is that RTBC patches against 8.1.x are not being automatically retested. For example, the final patch in #2287073: Allow views contextual filters to expose the context using argument validation plugins was not tested after October 22. I tried manually retesting it just now to see if that works.

8.1.x had been specifically excluded while it was not open for commits. https://bitbucket.org/drupalorg-infrastructure/drupal.org/commits/e49297... will take care of that in a few minutes.

That's been deployed. I believe there is some extra rate limiting for sending RTBC retests, so it may take some time to catch up.

Wanted to explicitly note that #2607956: Server support for Drupal 8 shipped config across projects (contributed modules) was rolled out last week. We don't have a lot of results yet but are hopeful :)

Thanks @drumm!

Adding #2651570: Bulk update all 6.x issues to 'Closed (outdated)' when support is dropped which is coming up soon.

Also adding an item that needs an issue for minor version management. Currently, it is not possible to tell from a core issue which branch the issue was tested against. Ideally we would fix #1171958: Allow files to be assigned to branch(es)/version(s) and thus tested against it, but in the meantime, we at least need to know which branch previous test runs were against. @drumm fixed a similar problem for project-level testing in #2268449: Run contrib module branch tests against both dev and latest stable core branches.

Patch test results in the core queue should show which core branch they were tested against.

I thought this might be trivial, but was mistaken. This directly corresponds to what is sent in for DCI_CoreBranch, which is for contrib tests only.

I think this should be lumped into #1171958: Allow files to be assigned to branch(es)/version(s) and thus tested against it. Issue files should be clearly associated with a version of the issue's project, for both core and contrib.

@drumm but we don't need to associate it for the minimum. At the time the test is run, we know what branch the issue is set to then. Why can that not just be reported in the UI?

The problem is that retest pills get added to the little patch rectangle even after the issue changes branches, but one can't tell which pills are from before and which are from after.

As a stopgap, I created #2664370: Add branch tested with to issue test pages to at least get the branch onto the results page.

I was thinking the branch on every test bubble would be redundant, but realized a patch might apply to both 8.0.x and 8.1.x. I updated the title of #1171958: Allow files to be assigned to branch(es)/version(s) and thus tested against it accordingly.

Thanks @drumm, that makes sense to me too.

https://www.drupal.org/project/issues/search?projects=&project_issue_fol... lists no issues. Does that mean this issue can be closed?

AFAICT the only open issue that is related is https://www.drupal.org/node/66484. But is that really a blocker?

Yep everything here is addressed now that needs to be. We have a process for the bulk updates and etc. Other things like supporting multiple branches we have process workarounds for. :)