On Fri, Apr 17, 2020 at 11:38 PM Frantisek Zatloukal <fzatlouk@xxxxxxxxxx> wrote:
On Fri, Apr 17, 2020 at 3:56 PM Kamil Paral <kparal@xxxxxxxxxx> wrote:I think this:"If the release is declared no-go, the bug loses last minute status."should be part of our policy. I considered it obvious, but I'm sure some people (/me looking at Frantisek) would argue. Let's put it there.I am against prohibiting use of last minute status if a release is no-go.
I think you misunderstand, there's no prohibition, it's nullification of the status in certain cases. Either way, I'm proposing a better process below - the status will simply get re-evaluated at the next meeting, which feels like the most reasonable thing.
Kamil, we already have "bugs proposed as blockers 5 days or fewer before the scheduled" in the last minute definition, I'd that's say that's specific enough.
That makes it clear *when* you can waive a blocker, if it was proposed too late. But we actually didn't define whether this "waive" status is effective only at that very moment, or indefinitely. In other words, is that waived blocker still waived the next week? Or will it be re-evaluated again next week (and that time, the last minute exception will not apply, because it will be more than 5 days)? There can be confusion about it.
There's even this sentence:
"In almost all 'exceptional' cases, the bug should be accepted as a
blocker either for the very next milestone release, or for the
equivalent milestone for the next release (if it would not violate the
criteria for the very next milestone)."
So if we move the blocker target to the next release, strictly following the protocol, and then declare the release no-go for some reason, we lose track of this bug completely. So perhaps we should clarify the steps:
1. Vote on blocker
2. If accepted, discussion exceptional state (last minute, hard to fix)
3. If exceptional AND release declared go, transfer the blocker status to the next release
4. If exceptional AND release declared no-go, do nothing and have the same conversion at the next go/no-go. The "hard to fix" status will probably still hold, but the "last minute" status will no longer apply (with 7 days slips; with shorter slips, it might still apply - but that's not a problem, we can simply confirm the decision from the previous meeting).
Also, we might want to preserve last minute "blocker waive" even if a release is no-go, consider having slip by one day (which is happening pretty frequently).
I think that's not technically called a slip but just a 1 day delay/punt. But above, I tried to phrase it in a way that works for all cases, regardless of the length of the slip.
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
