On Fri, Apr 17, 2020 at 11:38 PM Frantisek Zatloukal <fzatlouk(a)redhat.com>
wrote:
On Fri, Apr 17, 2020 at 3:56 PM Kamil Paral <kparal(a)redhat.com> 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.