quality/blockerbugs

Fork 0

Make repo tickets the canonical state trackers (not Bugzilla bugs) #302

New issue

Open

opened 2026-04-29 06:51:18 +00:00 by adamwill · 3 comments

adamwill commented

2026-04-29 06:51:18 +00:00

Owner

As things stand, the repo tickets created by blockerbugs only really serve as a voting location. We can do things like AGREED AcceptedFinalBlocker in them, and it makes something happen on the ticket, but that state doesn't really mean anything.

The current canonical state is tracked by the Blocks: and Whiteboard: fields of the bugs. That's what we use to define what's a proposed blocker, what's an accepted blocker, etc.

For several reasons, I think we should stop doing that, and make the repo tickets the canonical state trackers:

The Bugzilla whiteboard approach has always been a hack anyway
The loop between the app and the issue tracker is tighter and more controlled than that between the app and Bugzilla
Bugzilla may go away at some point, so we need a non-BZ way to do this anyhow
It would be useful to be able to treat things outside of RHBZ as blockers without having to create a paperwork RHBZ bug

I don't think this would even be too difficult. I guess the biggest change is that we'd have to stop treating a Bugzilla ID as the canonical identifier of a "thing" that's being tracked. I propose instead it should simply be...a string. We could require it to be a valid URL, I guess, or not. It would usually be expected to be a URL to some kind of issue - a Bugzilla bug, a GNOME issue, a KDE issue, whatever.

"Proposing something as a blocker/FE" would be achieved by opening a ticket in the tracker (of course, the web UI would be the recommended interface, it would mediate the process). I guess we can use labels or special text strings in the initial comment to represent what milestone and type the thing is proposed as. A thing would be proposed if the ticket was open and there was no AGREED action; other states would be determined by AGREED actions and represented...again, I guess, special comment text or labels (I like labels).

The web UI would just communicate the states as tracked in the issues. This would mean we could throw away, I think, all of the special-purpose code for communicating with Bugzilla; a Bugzilla bug would just be a "thing" that could be proposed as a blocker like any other "thing" in the world. We don't really need to communicate with any external systems if the state is all tracked in the repository we control, I don't think.

The only obvious drawback I can think of is that, if anyone's still using saved Bugzilla searches or anything rather than the blockerbugs web UI, that would stop working. I don't think that's a big deal. Obviously we'd communicate this and tell people "follow the web UI and/or the repo".

Can anyone think of any other drawbacks or issues with this idea?

As things stand, the repo tickets created by blockerbugs only really serve as a voting location. We can do things like `AGREED AcceptedFinalBlocker` in them, and it makes something happen on the ticket, but that state doesn't really *mean* anything. The current canonical state is tracked by the Blocks: and Whiteboard: fields of the bugs. That's what we use to define what's a proposed blocker, what's an accepted blocker, etc. For several reasons, I think we should stop doing that, and make the repo tickets the canonical state trackers: 1. The Bugzilla whiteboard approach has always been a hack anyway 2. The loop between the app and the issue tracker is tighter and more controlled than that between the app and Bugzilla 3. Bugzilla may go away at some point, so we need a non-BZ way to do this anyhow 4. It would be useful to be able to treat things outside of RHBZ as blockers without having to create a paperwork RHBZ bug I don't think this would even be too difficult. I guess the biggest change is that we'd have to stop treating a Bugzilla ID as the canonical identifier of a "thing" that's being tracked. I propose instead it should simply be...a string. We could require it to be a valid URL, I guess, or not. It would usually be expected to be a URL to some kind of issue - a Bugzilla bug, a GNOME issue, a KDE issue, whatever. "Proposing something as a blocker/FE" would be achieved by opening a ticket in the tracker (of course, the web UI would be the recommended interface, it would mediate the process). I guess we can use labels or special text strings in the initial comment to represent what milestone and type the thing is proposed as. A thing would be proposed if the ticket was open and there was no AGREED action; other states would be determined by AGREED actions and represented...again, I guess, special comment text or labels (I like labels). The web UI would just communicate the states as tracked in the issues. This would mean we could throw away, I think, all of the special-purpose code for communicating with Bugzilla; a Bugzilla bug would just be a "thing" that could be proposed as a blocker like any other "thing" in the world. We don't really *need* to communicate with any external systems if the state is all tracked in the repository we control, I don't think. The only obvious drawback I can think of is that, if anyone's still using saved Bugzilla searches or anything rather than the blockerbugs web UI, that would stop working. I don't think that's a big deal. Obviously we'd communicate this and tell people "follow the web UI and/or the repo". Can anyone think of any other drawbacks or issues with this idea?

adamwill added the

labels

2026-04-29 06:51:18 +00:00

kparal referenced this issue

2026-04-30 15:35:10 +00:00

Nominate upstream bug as a blocker #267

kparal added this to the Next BB tasks project

2026-04-30 15:35:56 +00:00

kparal commented

2026-04-30 15:50:25 +00:00

Owner

I'm sure we will find some obstacles when we actually start working on the implementation and digging deep into the implementation, but from top of my head, I don't see any showstoppers that would prevent us from using the suggested approach.

Currently we have a good Bodhi<->Bugzilla integration that BBA leverages well, and no counterpart with Bodhi<->Forge. However, this will be a desired functionality for "distgit in Forge" anyway, so hopefully somebody resolves that for us, and we can hook into it in a similar manner.

if anyone's still using saved Bugzilla searches

Ideally the Forge searches would work equally well. Which remind me, we'll need to look into using custom fields Forge, because it might provide structured data for consumers (BBA, searches, whatever) for data that don't map well to being labels.

Using Forge tickets to carry blocker state makes sense to me. The alternative approach is to keep everything in Blockerbugs' own native DB, but I was always wary about that - it involves additional work to have things queryable and exportable and any DB changes risk losing historical data. I like when somebody else carries that weight (Bugzilla, Forge, etc). Not to mention that there are more tools at your disposal because of their elaborate APIs, e.g. when you want to generate graphs or whatever. I'm sure we will find some obstacles when we actually start working on the implementation and digging deep into the implementation, but from top of my head, I don't see any showstoppers that would prevent us from using the suggested approach. Currently we have a good Bodhi<->Bugzilla integration that BBA leverages well, and no counterpart with Bodhi<->Forge. However, this will be a desired functionality for "distgit in Forge" anyway, so hopefully somebody resolves that for us, and we can hook into it in a similar manner. > if anyone's still using saved Bugzilla searches Ideally the Forge searches would work equally well. Which remind me, we'll need to look into using custom fields Forge, because it might provide structured data for consumers (BBA, searches, whatever) for data that don't map well to being labels.

adamwill commented

2026-04-30 15:53:15 +00:00

Author

Owner

Currently we have a good Bodhi<->Bugzilla integration that BBA leverages well

D'oh, I knew I was forgetting something.

I guess we could look at keeping relevant Bugzilla integrations for tracked "items" that are RHBZ bugs, so we still get all the status updates? And we also would want a mechanism to tag relevant Bodhi updates for non-RHBZ blockers.

> Currently we have a good Bodhi<->Bugzilla integration that BBA leverages well D'oh, I knew I was forgetting something. I guess we could look at keeping relevant Bugzilla integrations for tracked "items" that *are* RHBZ bugs, so we still get all the status updates? And we also would want a mechanism to tag relevant Bodhi updates for non-RHBZ blockers.

adamwill commented

2026-05-04 23:18:57 +00:00

Author

Owner

Thinking about it further...the Bugzilla status isn't the most important thing. The most important thing is the mapping from blocker issues to Bodhi updates.

I think we'd want a nice way to do this, in the new system. Labels, obvs, but maybe some kinda magic for tagging Bodhi updates as fixing blocker tickets, like we can for bugs? That might need work in Bodhi...

Thinking about it further...the Bugzilla status isn't the *most* important thing. The *most* important thing is the mapping from blocker issues to Bodhi updates. I think we'd want a nice way to do this, in the new system. Labels, obvs, but maybe some kinda magic for tagging Bodhi updates as fixing blocker tickets, like we can for bugs? That might need work in Bodhi...

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

quality/blockerbugs#302

No description provided.

Rows
Columns