Re: Blockerbugs discussion tickets feedback 🐞💬

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2020-11-20 at 13:45 +0100, Kamil Paral wrote:
> 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.

Hmm, those are reasonable points, actually. You might have convinced me
it makes sense to change the Bugzilla tags. We'd just have to update
the wiki policies and blockerbugs.

> 
> > 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.

Yeah, if we're going to change anyway, it may be worth requesting
keywords and switching to them.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
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




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux