[D8 EOL] Drupal 8 end of life: Drupal.org tasks to support the end of life process

Please don't mark them unsupported just because they are D8 only. It registers as a security issues you will trigger a mass security email notification which isn't really true.

The draft message to maintainers doesn't have any kind of timeline. I'm aware that this probably isn't set in stone yet, but as a maintainer I would expect that it says something about when exactly this will be done, especially if I somehow lived under a rock for the past year(s) and missed the whole D8 EOL thing and want to quickly port my project to Drupal 9 now. So maybe we could add a sentence about that with a blank spot for the actual date.

Also, there might be confusion between a project and a release/branch. So maybe add a FAQ to the effect that the project is safe, if it has compatible releases and only certain releases will be unsupported?

Another issue I see is about projects that only have Drupal 8 compatible releases that have known security issues (I actually know they exist, so this is not hypothetical, although if you want more details you would have to ask the security team, I won't tell you ;), Technically, unsupporting those releases should be enough, but end users might inadvertently conclude that this is only the usual D8 EOL, so they have nothing to worry about at least for a few months. See comment #4, it's an excellent example of that. Would those projects still receive the usual notification on the project page (along the lines of "This project has been marked unsupported due to a security issue...")? I think this is important, because as an end user I would like to know.

And finally, my response to comment #4:

Please don't mark them unsupported just because they are D8 only. It registers as a security issues you will trigger a mass security email notification which isn't really true.

Security advisory coverage really depends on the support from two groups: The maintainers and the security team. If one of those groups opts out of the process for whatever reason, you don't have coverage anymore, you won't get advisories for new vulnerabilities and there has to be some kind of notification to end users. Typically, in the Drupal universe, this is done by "unsupporting" those releases (and triggering that email, if your Drupal has been configured to send those). So this is really the right way to go. The only other option in my opinion would be to continue security coverage, but that's not really an option. As an end user I want to know, if a release I'm using no longer has coverage. I might have installed the project only, because it has coverage. And if I don't care, then I don't care about the release being unsupported as well. I can still use the release. So to the contrary, I would argue that those releases must be unsupported now. There is really no way around that, because otherwise it would be in violation of the "contract" between maintainers, security team and end users.

Could we retitle this issue to better indicate that it's the meta issue for all D8 EOL activities on d.o? The current language about "only contrib releases" is somewhat misleading.

Adding PSA link and 8.9.20 link.

For modules that are abandoned with a D8 only release I wanted to point out an edge case to be aware of. I’ve ran across some modules that have a dev branch that is tagged D9 compatible but the modules are either not actually D9 compatible or have no D9 release.

These modules were never included in the rapid acceleration process done earlier this year to transfer ownership to willing maintainers. Some security covered others not (so an SA would need to triggered unsupported)

Somewhat related are the modules that received the notice but closed it without actually acting on it.

Does anything process wise need to be created for those categories of modules to expedite continued development and if so would that need to be included in this mailing text? I know this is complicated by many of the modules with no D9 release having active D7 releases.

Some security covered others not (so an SA would need to triggered unsupported)

Maintainers can mark release series as unsupported at any time, no SA needed. We’re doing the same thing as that, for any release series where there is only D8 compatibility.

I know this is complicated by many of the modules with no D9 release having active D7 releases.

We are only marking any D8-only release series as unsupported, not doing any wider update to the project status or anything else project-wise, so this part is straightforward.

Opened #3252136: [D8 EOL] Remove project_analysis job (Drupal 8 to 9 mass compatibility checks) once Drupal 8 releases are marked unsupported as I think the job would cease to make sense once the outstanding releases are marked unsupported and thus be filtered out. Adding as the last step.

Adding link to https://www.drupal.org/psa-2020-06-24 for D7, flipping who is authoring this to the security team. And setting the date at December 6.

Fixing typo

Are there still steps to do here?

I don’t think so.