Remove supported releases for unsupported projects & prevent moving a project to unsupported if it has supported branches [#1511526]

This ticket is to get everyone's thoughts on removing supported releases when the project is marked unsupported.

Right now, if a project is flagged unsupported, but the releases are not, users are not informed of this. The security team has to go via its normal workflow.

We can fix this with a sql query for the current projects flagged as such. For current modules, we can make a change to drupalorg, to not allow the node to be saved, if there are releases flagged as supported.

Thoughts?

Comment	File	Size	Author
#1	projects_no_support.txt	34.27 KB	greggles

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

greggles

he/him

English

Denver, Colorado, USA

CreditAttribution: greggles commented 2 April 2012 at 13:45

Title:	Remove supported releases for unsupported projects	» Remove supported releases for unsupported projects & prevent moving a project to unsupported if it has supported branches
Status:	Needs work	» Active

File	Size
projects_no_support.txt	34.27 KB

When you say "users are not informed" you mean via update.module or on the project page or where?

I think we have to consider both the security team flow and a more "regular" flow. If a user marks their project as abandoned is it normal/expected for their branches to also be marked unsupported?

I think I'd be OK with some code in durpalorg that checks if someone is saving a project with "unsupported" as the term and it has supported branches on node/NID/edit/releases We could even start with adding this and maybe later do cleanup if that was necessary.

There are currently 536 projects in this state:
select distinct tn.nid from term_node tn inner join project_release_supported_versions p on tn.nid = p.nid where tn.tid = 13032 and p.supported = 1; Attached has a list.

Comment #2

kingandy CreditAttribution: kingandy commented 11 April 2012 at 10:56

Are individual releases "Supported"? I thought they were "Recommended".

When a module is "Supported" it implies that it is being actively maintained, and any bugs that arise will be addressed (either through development or by applying patches submitted by users). However, when a module becomes unsupported, the existing releases aren't suddenly unsuitable for use. Over time they may pick up more security vulnerabilities or more flaws may become apparent, but hopefully by (or at) that point some other interested party will have picked up development. Maybe an expiry date would be appropriate? Wait 2-3 months then move all "Recommended releases" to the "Other releases" state?

I certainly don't think projects with stable releases should be prevented from being marked unsupported if they're no longer being actively maintained. We have enough trouble working out whether a module has been abandoned as it is; preventing people from volunteering the information can only make it worse.