So far, I don't think there has ever been a deprecated, officially unsupported project (module or theme...).
But it's also unclear, what the steps are to achieve that. It's even unclear, if that's possible at all. Very likely help from someone with sufficient permissions on backdropcms.org is necessary.
I think, the approach - or to start with, the policy - should get documented somewhere.
1.4k contrib projects exist on GitHub, and people start to find broken, outdated, unmaintained, obsolete ones, which still show up in the installer. It doesn't seem ideal to leave all those zombies in an installable state (via Project Browser), because that means, site admins have to decide whether somethings safe to install, while they don't see the whole picture (last commit ages ago, open issue with warnings, might break the site worst case...).
The bug squad is a great idea, but not the solution for completely abandoned projects.
As PHP and Backdrop core move on, problems with those "zombies" will increase. At least, that's what I assume.
This may be somewhat difficult to address for various reasons.
Some projects may look abandoned to someone new looking at it and yet may show a number of installs. The number of installs may not indicate it is actually being used, or it may indicate use on old sites that are still present and becoming unmaintained themselves.
So what is the goal:
Alert new users that the project is unmaintained, dwindling in support, not necessarily a good choice, needs a new maintainer.
Alert existing sites where the module may be installed that it has become stale and they should review their use of it.
Marking projects as deprecated and work towards removing them.
The primary goal is clarity: what happens / has to happen if... ;-)
Currently, for example, I couldn't even deprecate my own projects, they will still show up in all project installers. And there's nothing I could do about it.
The other thing is: what happens with projects that are definitely unmaintained, and nobody wants to take over, and the project's already known to break sites only by installing (an extreme example, of course, but that can and will happen at some point, as PHP moves on).
Is it even (technically) possible to prevent such a rotten tomato from showing up in the installer? Be it, because a maintainer wants it, or because it's clear, that tomato will never get fresh again, as several attempts to fix the problems failed (example: a module that depends on a 3rd party service that has passed away).
There are probably several situations, where a defined way to sunset a project - clearly documented - is beneficial. Currently I don't think, there is a way.
I’ve been looking into different ways to handle integrations more efficiently, and the approach you mentioned here clarifies a few things I was stuck on. Definitely going to try implementing...
It’s really interesting that clearing out the menu_links table and reinstalling the Admin Bar module did the trick. Menu corruption is such a common headache when moving from D7 to Backdrop,...
Restore Newsletter Subscriptions from a Dev Website
In my last comment, I described a way to restore newsletter subscriptions from a database backup. The method involved directly editing...
Posted1 day 8 hours ago by Olaf Grabienski (Olafski) on:
I am considering migrating my drupal 7 website to backdrop.
Hi @seamus, I would like to offer my professional services for migration to BackdropCMS.
Please connect If...
Posted2 days 3 hours ago by Deep Vyas (deepvyas) on:
Restore Newsletter Subscriptions from a Database Backup
One of my websites was affected by the Simplenews issue, and there were many incorrectly disabled newsletter subscriptions of '...
Posted2 days 5 hours ago by Olaf Grabienski (Olafski) on:
Comments
How to deal with abandoned projects?
So far, I don't think there has ever been a deprecated, officially unsupported project (module or theme...).
But it's also unclear, what the steps are to achieve that. It's even unclear, if that's possible at all. Very likely help from someone with sufficient permissions on backdropcms.org is necessary.
I think, the approach - or to start with, the policy - should get documented somewhere.
1.4k contrib projects exist on GitHub, and people start to find broken, outdated, unmaintained, obsolete ones, which still show up in the installer. It doesn't seem ideal to leave all those zombies in an installable state (via Project Browser), because that means, site admins have to decide whether somethings safe to install, while they don't see the whole picture (last commit ages ago, open issue with warnings, might break the site worst case...).
The bug squad is a great idea, but not the solution for completely abandoned projects.
As PHP and Backdrop core move on, problems with those "zombies" will increase. At least, that's what I assume.
This may be somewhat difficult to address for various reasons.
Some projects may look abandoned to someone new looking at it and yet may show a number of installs. The number of installs may not indicate it is actually being used, or it may indicate use on old sites that are still present and becoming unmaintained themselves.
So what is the goal:
There may be more goals.
The primary goal is clarity: what happens / has to happen if... ;-)
Currently, for example, I couldn't even deprecate my own projects, they will still show up in all project installers. And there's nothing I could do about it.
The other thing is: what happens with projects that are definitely unmaintained, and nobody wants to take over, and the project's already known to break sites only by installing (an extreme example, of course, but that can and will happen at some point, as PHP moves on).
Is it even (technically) possible to prevent such a rotten tomato from showing up in the installer? Be it, because a maintainer wants it, or because it's clear, that tomato will never get fresh again, as several attempts to fix the problems failed (example: a module that depends on a 3rd party service that has passed away).
There are probably several situations, where a defined way to sunset a project - clearly documented - is beneficial. Currently I don't think, there is a way.