Voting starts in March for the Drupal Association Board election.
As a follow-on from:
One of the main sticking points is the extra burden that this proposal would place on the Drupal security team, who already struggles with wrangling Drupal core security releases given only two active branches.
Quoting from greggles in:
I am -1 as it stands today.
Reiterating what I said a few times in #586146: [policy, no patch] Decide if and how to implement semantic versioning for Drupal 8.x .
Any proposal that increases work for security team (especially for D6, but even for D7+) without addressing the workload of the security team is a non-starter from my perspective. It's not really the security team as a whole, but specifically people working on core security issues. If we say "The people in MAINTAINERS.txt need to fix security issues in their area" I'm open to that - the answer doesn't have to come from the security team.
As it stands, this proposal does increase work for the security team and doesn't seem to address that.
"The people in MAINTAINERS.txt need to fix security issues in their area" would be a very similar process to the one the security team uses for contrib modules right now, and it would help spread the load out among 60+ people, each of whom is arguably the best people to do the work. It'd also allow us to ferret out inactive maintainers to keep the doc up to date. It seems like a reasonable request to me. What say you?
Do not release 8.0.0 until all critical and highly critical security issues are fixed
This means that issues that are critical in the security.drupal.org tracker would be included as release blockers, and hence prevent a release or release candidate as well as public critical bugs/tasks.
Advantages; will ensure there is zero backlog of known serious security issues when 8.x is released.
Disadvantages: potentially a 6.x or 7.x port of a security issue could hold up 8.0.0, however this is also an advantage depending on your point of view.
Do not release 8.1.0 until all critical and highly critical security issues are fixed
- Instead of a one-time injection of core developer attention on the security queue in order to release Drupal 8.0.0, this would instead happen on a cycle at least once every 6 months, helping with general sustainability of core security releases.
- Working through the security backlog ahead of releasing a new feature release means the next release there are (hopefully) very few (and possibly no) issues to work on.
- Core developers in theory will be more motivated to help with security issues if they are blocking features they care about getting released.
- Puts the "every 6 month" release commitment heavily at risk, if current trends regarding open security issues continue.
- Holding up releases on 0 criticals (never mind security-related criticals) generally means never releasing (observe the first ~5 months of Drupal 7's release), and holds up other critical bug fixes from getting released and tested.