Try using BRE (Bugzilla Rules Engine) to set up a template for Fedora bugs, referring to blocker/FE process #733
Labels
No labels
agile
anacondawebui
arm
blockerfe
Closed As
Duplicate
Closed As
Fixed
Closed As
Invalid
Closed As
Wontfix
Closed As
Worksforme
coreos
criteria
defect
easyfix
enhancement
iot
meeting
meta
onboarding call
proventesters
retrospective
silverblue
sponsor
test cases
test days
wiki
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
quality/tickets#733
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is a transfer of https://bugzilla.redhat.com/show_bug.cgi?id=1891912 into our issue system. The idea there is this:
"We (the Fedora QA team) were recently talking about a situation we see where what turns out to be a critical Fedora bug is filed, but doesn't really get any attention. For instance, https://bugzilla.redhat.com/show_bug.cgi?id=1889090 turns out to be something we would really have wanted fixed for Fedora 33 Final, but it was not nominated as a release blocker or otherwise escalated to anyone's specific attention, and obviously the kernel maintainers didn't get to it among all the other kernel bugs in time.
One suggestion was that Bugzilla could somehow provide information on the Fedora release criteria and blocker/FE process during the process of filing a Fedora bug, whether as part of the initial template or just as a text block somewhere in the process, or something along those lines.
There are possible objections to this: on the one hand, filing a bug is already a long and complex process that throws a lot of text at you, and adding more might just make it more intimidating while probably being ignored by many reporters. On the other hand, if people do pay attention to it, we could get lots of not-really-that-critical bugs being proposed as blockers. But even so, it may still be worth trying, so I figured I'd file a proposal for it."
This was filed as a bug against Bugzilla as we assumed someone else would have to actually implement this, but the Bugzilla maintainer @jfearn told us Bugzilla actually has something called the BRE (Bugzilla Rules Engine) which we should be able to use to implement this. To get it out of BZ and off Jeff's backlog, I'm moving it here. If it turns out we still need help, we can re-open that bug or get in touch some other way.
Reposting my comment from chat:
we link to How to File a Bug docs in the Bugzilla "product description". i could either add something about it on that page or add a link to something in the product description itself. I'm not sure if anyone actually looks at the description, but at least we could say we tried.
Doing something with BRE for critical path (or similar) packages could be a good thing to do in addition, but either of the above implementations are approximately 5 minutes of work on my part.
I never got around to this. Given the vibes around bugzilla going away in the middle term, and my backlog, let's just give up. Giving up is okay, right?
Metadata Update from @adamwill: