in the discussion about severity levels for security issues we came across the fact that we don’t treat all blocker issues equally. Originally, the idea was that you cannot release when there are open blocker issues (for this reason, there is an explicit check in the release plan if there are blocker issues).
With this vote, I propose to restore the original meaning of the “Blocker” priority and to use the “Critical” severity for important, non-blocking issues. To be more precise, I propose the following new meaning:
Blocker issues must be closed before releasing a version that is affected by the blocker.
Critical issues should be handled as soon as possible, if they haven’t been fixed before the next roadmap, they must be fixed as part of it.
As part of implementing this vote, all existing critical issues need to be reviewed if they are that important, otherwise, they’ll be changed to “major”.
I’ll open separate votes to change how we classify security issues and regressions to reduce the number of blocker issues to ensure that this new procedure can actually be implemented.
Regardless of that, the idea is that we can use the “Critical” priority to mark issues that are so important that they should be fixed in the next roadmap the latest. Just to make this clear, this is not a “wishlist” feature, setting a critical priority should be an exception and definitely not a way for users to prioritize what they would like to see implemented/fixed. Instead of fixing an issue, we can of course always decide to decrease the priority of an issue if it isn’t important enough.
This vote is open until June 16, 12:00. Thank you very much for your votes!
-1 because of the terminology and the consequences. I feel it’s more important to continue doing time-boxing than to delay the release because of blocker issues. For one, because the current version in progress can contain blocker issues that have been fixed already (or very important issues) and they will be delayed for the users because one or several other Blocker issues are blocking the release. In other words, I don’t want a Blocker to block the release until it’s fixed and this lasts, say, 15 days.
I’d be +1 to say that we need to prioritize Blocker issues for the current release as much as possible by assigning them to developers right away (ie there should be no blocker issues without a dev assigned). I’d also be +1 to allow delaying the release by 1 to 2 days at max for giving the time to fix a blocker issue. I’d also agree to, exceptionally allow delaying to 3 days when we’re releasing a RC by doing a proposal/vote and in this case, we’d skip the RC release and go straight to the final release.
More generally, I’m +1:
to say that we must try to fix Blocker issues in the current version being prepared
to say that we must try to fix Critical issues in the coming releases.
I’m -0 to -1 to only allow a max of 2 releases for fixing Critical issues. I’d prefer 3 releases (ie 3 months). That would also align us with the “Critical” security issues which have 3 months to be fixed. One rationale is that it’s hard to know in advance when we’ll have time to work on Critical issues as plans change often and 3 months would give us a bit more margin, and I don’t feel that it’s too much.
Some questions remain:
Should a Critical issue be relabelled as Blocker when only 1 release remains for it?
Consequently what is the rule re assigning devs to critical issues. IMO we should do a best effort to assign them a dev ASAP (even if the issue is only going to be fixed in 3 months), and apply the Blocker rule when only 1 month remains (ie always set a developer when preparing the roadmap).
My calculation of 90 days on security issues is based on this proposal, my idea wasn’t to treat critical security issues differently. The 90 days consist of:
Up to 30 days for roadmap 1 in which we wouldn’t need to work on the issue yet.
30 days for the next roadmap 2 in which we would need to develop a fix.
Up to 30 days for releasing all branches as at the end of a roadmap, we don’t release all branches, only master. I know that the idea is to have LTS releases as frequently as every 14 days but in reality I think it’s more like every 30 days.
This calculation is based on worst-case assumptions, but the idea is really to have a maximum of 90 days in the worst case as reporters usually threaten to release details of the security vulnerability if no fix is available within 90 days. If we allowed 90 days for Critical issues, it would mean that we might need 120 days for releasing security fixes which would be too long.
My understanding was (but I didn’t search carefully) that the current definition of Blocker is that we cannot release when there is a blocker. At least my intent wasn’t to change the definition of a blocker issue with this vote, my assumption was that this is basically the current definition of a blocker issue, sorry for not making this clear. Could you point me to our current definition of a blocker issue?
I tried to keep the rules for “Critical” issues as simple as possible without the need to do any complex calculations based on when the issue was opened. The only thing we would need to do with my proposed definition is to put them on the roadmap whenever we prepare one. Unless we decide to mark more issues as “Critical”, we would only mark issues as “Critical” that were blockers so far. Thus, I believe it is justified to put them on the next roadmap and not delay them further. To me, a three-month period would seem harder to implement and keep track of.
Of course, as it is now, there can be exceptions, we can still decide to release with open blocker issues as we do now (the idea would mainly be to make it a real exception and not the norm), and while a committer who is assigned to an issue on a roadmap is supposed to fix that issue during that time period, this might not actually happen.
Until now the time-boxing aspect has always taken precedence over a Blocker issue, except when we can fix that issue by delaying only by 1-2 days (we accept a small delay to time-boxing), and exceptionally by 3 days and in this case, we usually send a proposal to skip the RC (or agree on the xwiki chat). Example: Skiping 11.10RC1 release).
Ok thanks for the precision. There are still consequences so let’s be more clear Hence my proposals to clarify.
I don’t think we’ve written one. I’m sure it was discussed on the chat + on the old mailing list but I haven’t found a place on xwiki.org.
That’s a definition of a Blocker, not of a Critical
We define the next roadmap only at the end of the month (when the RC is released). We can use “Critical” to indicate “Candidate for a Blocker in the next roadmap”. I still feel that there are critical issues for which we will need more than the next release to fix because of lack of time. And marking them as major would loose the information that we need to work on them ASAP.
I have the impression we want the same thing, we just don’t agree on the wording. Let me try again formulating this with other words:
A blocker issue is an issue that is so important that it should ideally be addressed before the next release, but there can be cases where we release nevertheless, in particular if the issue is discovered directly before the release, and it’s not, e.g., the final release after an important regression was introduced in the RC. Blocker issues should be issues that are so important that we delay some items of the current roadmap to handle them.
A critical issue is an issue on which we should work ASAP, but that can also wait for the next roadmap. It should be planned with priority for the next roadmap if we don’t find the time to handle it immediately, but of course there can be cases where it just doesn’t fit, and we might decide that it can also wait another month.
In practice, the main change I expect is that when preparing a roadmap we’ll look at all Critical issues and include as many of them as possible in the roadmap. Of course, as I’ve mentioned above, we need to clean up the issues that are currently marked as Critical first before we can realistically start this.
I hope that this clarifies a bit how I meant this. If not, I suggest having a meeting to clarify the formulation as I’m not sure that we’ll reach a conclusion here.
