Bulk update Drupal core 7.x issues after Drupal 7 EOL

Yes, the simple comment is clear. What will be the status of the issue?

However, there are D7 issues that are open and have a commit for Drupal 8+. Those issues need to be identified so that credit can be applied before they are closed. Perhaps this should be a child issue with a list of all the issues in the summary?

Of the 21260 total open core issues, 4680 are against 7.x: https://www.drupal.org/project/issues/drupal?text=&status=Open&prioritie... →

How would we go about figuring out which ones are backports? Do we mean the 66 issues that are explicitly marked "Patch (to be ported"? https://www.drupal.org/project/issues/drupal?text=&status=15&priorities=... → (I think this is a good dynamic link, why do we need to manually list them in an issue?)

For the status, I would probably go for 'closed (outdated)'.

Many open Drupal 7 issues have been fixed in Drupal 10/11 in a different d.o issue, so it's not that we took an explicit decision to reject the issue, it's that it didn't get completed in Drupal 7 before the EOL. In some cases they'll reference the fix that went into 8+ but not always (like a lot of duplicates).

According to this Slack discussion https://drupal.slack.com/archives/C079NQPQUEN/p1734040568387179 @quietone somehow filtered the list of open D7 issues which already seems to have commit and a 'needs backport to D7' tag to "just" 113:

Did some work on this and I've got 113 open issues that have a commit message. That is D7 issues tagged with 'needs backport to D7'.

I think that it is a good idea to review at least these issues for missing credits and close them properly as Fixed. Maybe d.a. can help with a custom query to verify this number if needed? Otherwise I agree with closing all others with status Closed (outdated). They will be still indexed by search engines, so if someone runs into an issue which is still relevant for D11+, it can be reopened. But I expect most of them to be not relevant anymore.

Should the search be for all open issues that have a commit? The 'patch to be ported' issues will be part of that group, but not all. For example, #534594: [meta] system info cache writing and registry rebuilding is broken without a full bootstrap → , was committed and re-opened for tests and it had many status changes since then. And if so, would credit be applied up to the commit, but not after?

Should the search be for all open issues that have a commit?

I think that ideally yes, but hard to say if that will be doable, without knowing the number of issues we will need to review/close manually in such case.

As now also closed issues can get credits ( ✨ Grant credit for all closed issues, not just fixed issues Active ), do we need to make an exception here and disable all credits for old D7 issues which will be auto-closed by this script? I think we probably do not want credits added as there will be a lot of issues with pre-filled credits field from the past and that is not verified.

I recall using my list and moving some issues back to D8 and assigning credit for the commit. It was tedious and time consuming work to fix mistakes made in the past about issue management. I actually think my time for working on is better spent on current issues and discussions.

I thought it prudent to look at my list and to determine how many issues are left to check. Turns out I can't find it. All I know is that the issues to check are less than 113.

This was discussed by the committers and the DA at a monthly meeting. We all value the work of contributors and want to acknowledge their work through the credit system. We also know first hand that adding credit is demanding and takes time to get right. The people who can add credit are also the committers who already have a backlog of issues in the RTBC queue. In the end, it was decided it in the best interest of the Drupal project that credit is cleared for all open core Drupal 7 issues and then they are closed.

participants: catch, drumm, longwave, Jpoker10 and myself.

In D6 issues, we added the following comment:

Automatically closed because Drupal 6 is no longer supported → . If the issue verifiably applies → to later versions, please reopen with details and update the version.

So I suggest to use slightly modified message here, something like this (added the part what to do if the issue still applies to D10+):

Automatically closed because Drupal 7 security and bugfix support has ended → as of 5 January 2025. If the issue verifiably applies → to later versions, please reopen with details and update the version.

The link to all currently open D7 issues should be this: https://www.drupal.org/project/issues/drupal?status=Open&version=any_7 → .

I added the proposal from #11 and the link to the issue summary.

All comments here have been supportive and this was also discussed in a DA / core meeting. Since there are no objections I am setting this to RTBC.

This will update 4,681 issues, which lines up with https://www.drupal.org/project/issues/drupal?text=&status=Open&prioritie... → . The over-count is unpublished issues, which will also be updated.

The test issue for review is #6463: Add static caching for user_roles() → . I’ve confirmed it did have draft credit assigned, which was cleared.

This needs core maintainer approval before I start the bulk update.

I had a quick look at #6463: Add static caching for user_roles() → and it looks good to me.

Message looks good and credits are cleared. +1 from me. Thanks!

Thanks, this update is starting to run

Bulk update complete!

Nice, thanks!

Are there any plans for contrib Drupal 7 issues?

@ivnish Not sure if there is an issue for contribs yet (have not found it), but feel free to create one to discuss it. Thanks.

I created 📌 Bulk update contrib 7.x issues after Drupal 7 EOL Active

Automatically closed - issue fixed for 2 weeks with no activity.