On Thu, Nov 19, 2020 at 6:08 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
> The only difference seems to be in FE vs FreezeException, and then in
> having "AcceptedBlocker" in the Whiteboard instead of AcceptedBetaBlocker
> and AcceptedFinalBlocker. Perhaps we could fix at least the latter in
> Bugzilla? It is inconvenient anyway to not be able to distinguish Beta vote
> from the Final one.
In Bugzilla it's redundant, though,
Why do you consider it redundant? Currently we can't mark a blocker to be accepted for Final and rejected for Beta, we have to remember it or add it as a comment somewhere. We can't make it visible. We also can't accept it for Final and leave the Beta decision for later. I really find it annoying sometimes.
and having the milestone in the
string could produce the hard-to-resolve paradox of a bug e.g. blocking
BetaBlocker but marked AcceptedFinalBlocker - what is blockerbugs
supposed to think of that?
It's not a paradox, that's a human mistake when marking the blocker. Blockerbugs would interpret it as a proposed Beta blocker and no information regarding the Final blocker (not proposed, not accepted, not rejected).
If we have AcceptedBetaBlocker and AcceptedFinalBlocker, we can actually simplify Blocks: keywords and only use "Blocks: F34Blocker", i.e. we wouldn't need F34BetaBlocker and F34FinalBlocker separated. This makes it even easier for the person proposing the bug, they don't need to understand the difference. And it would avoid the possibility of the human mistake mentioned above.
That one we might just have to leave, I think. Note technically there's
nothing to fix in Bugzilla: these strings have no special meaning to
Bugzilla itself at all. The things that make them magic are:
1) The wiki policy pages
2) blockerbugs
3) Saved Bugzilla searches
Sure, Bugzilla keywords just limit the decisions we can specify in a structured and programmable way. I think it's worth improving eventually. I'm not saying we need it right now. But if we continue to raise the requirements for blocker automation (like https://pagure.io/fedora-qa/blockerbugs/issue/149 ), we'll need to fix it somehow. Currently discussion tickets can express more states than Bugzilla, and that's problematic for any synchronization. We can talk about it in the ticket.
> Or (and this might be actually a good idea! ;) ), should we start showing
> the long form in the ticket description in the voting summary (i.e. people
> not familiar with our process will still have a chance to understand the
> voting summary), and allow people to submit their votes in both forms?
Yes. Same as the point below. There's no reason to be overly
prescriptive when accepting votes, if a string clearly and unmistakably
identifies a specific vote, we should take it.
_______________________________________________ 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
