I wonder if we could just change the template for rawhide and branched(if exists), but leave stable releases alone?

Anyhow, I think adding a short thing like "If you feel this bug may be a freeze exception or blocker for an in progress release, please see..." type of thing would be fine.

There's also lot of automation available in bugzilla which Fedora doesn't currently use - but it could if it wished to.

Templates are tied to product/components - and we can now edit them (via Service Now ticket) without a software release.

(In reply to Alasdair Kergon from comment #2)
> There's also lot of automation available in bugzilla which Fedora doesn't
> currently use - but it could if it wished to.

Cool. Is there documentation we could look at? Or perhaps we could do a short meeting with an overview?

It would be nice to know whats available automation wise that we could leverage...
 
> Templates are tied to product/components - and we can now edit them (via
> Service Now ticket) without a software release.

Cool. Would it be possible for us to be able to change it via script?

I think there was also a suggestion for us to try this out for "critical packages" and see how it turns out.

@sumukher it might be good idea to explicitly mention folks filing bugs during test day to check out the release blocking criteria or freeze exception in bugzilla before filing.

I agree with Adam that adding more text to a wall of text may make the user experience work. I think if we put a sentence or two at the top of the template saying something like "If you think this bug should block the next Fedora release, nominate it at: <URL to BlockerBugs app>" that might help address the issue while also not making the experience worse. Hopefully it doesn't result in a barrage of clearly-not-blockers submitted as blockers, but if it does, we can adjust. I'm less keen on the idea of only having that on particular releases because that gives us another switch to flip on release day. That isn't the worst thing, but as a switch flipper, I'm interested in not having to do more work. ;-)

Another idea for consideration is to use an approach more like we do for the prioritized bugs process where it's a flag on the bug itself. That would require a lot of changes on the QA process and tooling side, so it's not ideal. It also suffers from process-knowledge bias since flags are hidden by default. Someone would have to know to look for the flag, and in that case, they probably already know about the blocker app. So really this is probably a terrible idea, but I'm throwing it out there for completeness.

I second Kevin's request for docs or an overview meeting. I'd love to know where we could be making Bugzilla more useful or more efficient for our uses.

> I think there was also a suggestion for us to try this out for "critical packages" and see how it turns out.

I'm not sure how I feel about this. The trouble is that we block on behavior, not packages, and I think a list of "critical packages" in that respect would be quite large and probably more dynamic than we'd like. It might serve as a good testing ground, but I wouldn't want to leave it as a final state.

Blocker status *is* effectively metadata on the bug itself. The canonical definition of a proposed blocker is "bug that blocks one of the blocker trackers". The canonical definition of an accepted blocker is "bug that blocks one of the blocker trackers and has AcceptedBlocker or AcceptedPreviousRelease or Accepted0Day in its whiteboard field".

The blockerbugs app is only a helpful wrapper around this; there's no actual need to use it for anything. All the blocker proposal workflow actually does is does is set the bug as blocking the appropriate tracker and add a comment. We only added that workflow because apparently learning/finding the conventions for blocker bug aliases is a hurdle for blocker submission, so we added the submission flow to the blockerbugs app so people don't have to do that (also people were finding blockerbugs one way or another and 'naturally' expecting it to be possible to propose a blocker from there).

Before blockerbugs existed we handled blockers with custom Bugzilla searches (those still actually exist and I use them occasionally); we haven't changed how the process fundamentally *works* since then at all, it's still exactly the same, blockerbugs (and now pagure async voting) are just icing on top. You could turn them both off tomorrow and the process would still work, it'd just be a bit clunkier.

We use tracker bugs and the whiteboard more or less because we always have. Use of tracker bugs especially may date to before flags were really a Thing - the earliest ones I know of were for Fedora 10. We use the whiteboard rather than keywords because every time we want to add or change a keyword we have to ask a Bugzilla admin and that used to be a real pain. We could theoretically change those things, but I don't think any possible change there is a straightforward improvement, they're all tradeoffs. To the point of this bug, especially, I don't think we can really improve the 'visibility' of the process by making any such change - as you say, flags are hidden in the UI by default so using flags instead of tracker bugs wouldn't really make the system stand out in the UI at all. Even when they weren't hidden by default they were kinda confusing and scary (which is probably why they're hidden by default now). Even keywords are only listed if you explicitly go to the keywords box and look for them.

If we could somehow add a "Bug Is A Release Blocker" checkbox (I'm simplifying...) right in the really visible bit of the UI, *that* would potentially be a benefit, but doing that isn't that simple I don't think.

> Blocker status *is* effectively metadata on the bug itself.

Right. By "flag on the bug itself", I meant specifically a Bugzilla flag. For the Prioritized Bugs process, we have a fedora_prioritized_bug flag. Anyone can nominate a bug by setting that to '?'. After the Prioritized Bugs meeting, we accept ('+') or reject ('-') it. So in this case, we wouldn't use "blocks the tracking bug" metadata, we'd use the "has fedora_blocking_bug+" metadata instead. It would change how the app queries, etc, but it puts the nomination in the bug itself (without having to know which bug to set it blocking, etc).

https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/ describes the Prioritized Bug blocker process.

For this purpose, we would need many flags: beta blocker, final blocker, beta FE, final FE, 0day blocker, previous release blocker. We could use the version on the bug report to handle the difference between, say F34 and F35 bugs. This isn't entirely great, since it means a lot of switches to flip, but it would only be on Fedora bugs, so it's not like it would get in the way of other BZ users. Or we could develop a new process that would simplify the BZ implementation (I happen to think the current process works pretty well, and I'm not sure it's worth changing it to make Bugzilla easier, but we *could*)

yeah, you certainly *could* handle it with flags, but I just don't see that it's actually an improvement in any practical way, really.

The only practical improvement is putting the nomination process in the bug in a more obvious (but hidden by default) way. I don't think it justifies the effort required to accommodate it. (I think we're in violent agreement here).

If @agk doesn't have better suggestions, I think a one-liner at the top of the template is the best way to go.

Hi, I think Alasdair is talking about the Bugzilla Rule Engine (BRE). https://bugzilla.redhat.com/docs/en/html/integrating/api/Bugzilla/Extension/RuleEngine.html

I'm also guessing he is thinking about using the BRE to add a comment with further instructions. So a person opens a bug and then the BRE adds a comment to the bug with some extra docs. A good thing about this approach is that the comment gets added regardless of the way the bug is created, but since it's the BRE you can also exclude doing that if the user is in a group or many other conditions.

Bug templates are set per component, it cannot, currently, be affected by product versions. There is no API for editing bug templates.

There is a guided process for creating bugs, it's a link on the bug creation page, maybe that is suitable? Maybe it should be the default path for fedora bugs? This isn't currently possible but it shouldn't be a big change.

e.g.

https://bugzilla.redhat.com/enter_bug.cgi?format=guided&product=Fedora

You can have custom templates, so that page could be very specific for Fedora. It wouldn't affect bugs created via the API or the unguided path.

Example guided bug entry templates:

https://pagure.io/Red-Hat-Bugzilla/rh-bugzilla/blob/master/f/extensions/RedHat/template/en/default/bug/create

FWIW Adding a single, or multi, select drop down with a bunch of blocker types is easy. CF's have some decent ACLs so once the field is created we can grant admin rights to a Fedora group and you can manage it.

e.g. cf_fedora_blocker field with beta blocker, final blocker, beta FE, final FE, 0day blocker, previous release blocker.

A check box is actually harder as it modifies the schema of the bugs table and thus requires an outage to add.

The benefit of flags is that they fit a propose/ack/nak workflow better than custom fields do. If the issue with them is how they lay on the page, then maybe that can be addressed.

IMO if you are discussing blockers for different stages of the product release cycle, beta/final/etc, then you probably only need one flag; your process needs to know what phase the release is in, the user shouldn't have to know that.

Also use of BRE can now also be delegated, so you would be able to maintain and tweak any 'rules' directly yourselves.

You can try out the rules engine on partner-bugzilla - I've given Adam the details.

@awilliam any luck testing the BRE? If so was it suitable?

Oh, jeez, sorry, this fell off my priority list for long enough that I entirely forgot about it. I'll try and get back to it, but the F36 crunch time is gonna start soon, so, y'know...yikes.

Hi, I am cleaning up the back log, is there any action required on this bug or should we close it?

Sorry Jeff, this is still on me. It keeps falling off my list because it's just not a high priority.

I tell you what - let's assume the BRE should be enough for this until proven otherwise. I'll file a ticket on our team tracker for trying to set this up using the BRE. Then we can just bug you if we actually need any change.

Maybe we'll get to it before Bugzilla gets closed down? :D

Moved to https://pagure.io/fedora-qa/issue/733 .

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days