- 🇪🇨Ecuador jwilson3
Is the only thing blocking this project from opting into security coverage the risk of previous maintainers introducing a security risk? It seems counter intuitive.
- 🇺🇸United States greggles Denver, Colorado, USA
There are 8 maintainers of the module and 6 of them can opt it into security coverage.
I think what bmcclure is saying is that it shouldn't be opted into security coverage until it is more stable - that's a tempting idea in general but I find it's better to make a "X.0" that has security coverage sooner than later since the release blockers are often not as blocking as we think when evaluated in the long-run of time.
@Anybody, I don't think the long inactive maintainers are a particular risk, but if you do then here's what I propose:
1. File an issue describing the process of removing inactive maintainers. Ask all maintainers to comment on it within a month.
2. Send a contact message through the d.o contact form and slack message for those on slack to all the maintainers who support them telling them about the issue.
3. Wait a month.
4. Remove maintainers who didn't comment, while being willing to add them back if they regain interest in the module. - 🇳🇱Netherlands koosvdkolk
Any update on this? For us this is also a blocker.
- 🇨🇦Canada chrisck BC, Canada
Following @greggles suggestion, although I'm not a maintainer, I would be happy to write this up in a new issue and start the process including reaching out via contact form and slack - unless there are any objections?
- 🇩🇪Germany Grevil
@Anybody, I don't think the long inactive maintainers are a particular risk [...]
I agree with @greggles here, especially if 6 out of 8 maintainers can opt into SC themselves. We COULD create a minor follow-up issue for this, but I don't see the necessity.
Automatically closed - issue fixed for 2 weeks with no activity.