Red Hat Bugzilla: GNOME packages are in bad shape #131
Labels
No labels
a11y
btrfs
Closed As
Can't fix
Closed As
Deferred to upstream
Closed As
Fixed
Closed As
Won't fix
default-apps
easyfix
experience
help-wanted
installation
meeting
meeting-request
nvidia
packaging
pending-action
qa
testing
user-docs
wg-docs
wg-meta
No milestone
No project
No assignees
20 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
workstation/tickets#131
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?
I think most Fedora GNOME developers have simply given up on Red Hat Bugzilla. Currently, it's where bugs go to be ignored and receive no response, including serious bugs. This status quo is unfair to users.
Downstream, we are generally only passingly familiar with the packages we own, and we do not have time to even look at most bugs, let alone triage them. I checked a couple other GNOME maintainers to see how many bugs are assigned to them and found: 260, 182, 420, 511, 372. The only reason I don't have this many myself is that I don't own dozens of packages, unlike most of the other GNOME maintainers. These numbers are way too high for us to practically deal with triaging them. And we can't practically move the bug reports upstream either; it just takes too long, we'd spend so much time moving bugs that we'd never get anything else done. We need the bug reporters to do that for us.
So reality is: we need to get the bugs upstream to be able to not ignore them. Upstream maintainers generally have dramatically fewer packages to maintain (usually only a couple packages rather than dozens) and much more specialized expertise in their packages. Upstream, there's a decent chance the bug reports won't be ignored, if the maintainers are good about managing their issue trackers. Some GNOME maintainers are good at this. Some are not. To the extent upstream maintainers ignore their issue trackers, that's a separate issue and one that is more solvable than the mess we currently have on Red Hat Bugzilla. Upstream, the bug reports at least go straight to the right developers. Downstream, on Red Hat Bugzilla, there's just no chance. We'd need way more downstream developers just to look at all the bug reports we receive.
I suggest we set up an automated script to close all bugs in GNOME packages, except bugs that are marked with some flag or keyword to indicate the issue is (a) a downstream packaging issue, (b) a proposed blocker, freeze exception, or Fedora priority bug.
This is related to #130.
Metadata Update from @chrismurphy:
Is GNOME the only upstream where this is an issue?
No, this is also a problem with KDE. I'm pretty sure @rdieter would like to see this work for submitting to KDE Bugzilla too.
However, I think it makes more sense to file the bugs both upstream and downstream, and have linked bug reports in both directions. That way Fedora processes still work, and GNOME/KDE people can focus on upstream reports.
I suppose it might also be a problem for Pantheon (@decathorpe can chime in on this)...
To some extent, yes. (TL;DR at the bottom)
For example, GNOME upstream changes DBus interfaces or GSettings schemas with almost every major release, and those changes often introduce crasher bugs in Pantheon / elementary apps. And since new GNOME versions always land in fedora at the last possible minute, this makes it pretty hard for me to keep Pantheon working on stable releases ...
These changes are not necessarily upstream "bugs", but they still frequently break things in fedora - so I always thought that reporting them in GNOME GitLab was the wrong place and opened bugs in RHBZ instead.
However, it often takes weeks for somebody to look at those bugs (if at all), at a time where fixes would be time-critical (just before the final freeze, usually). For fedora 31, I was only able to fix Pantheon after GA (due to the switch to systemd user session stuff completely breaking Pantheon), which was ... not good. It is often more productive to ask elementaryOS upstream devs for help to come up with workarounds than to wait for somebody to respond to my RHBZs.
(Just to clarify: I think that elementary upstream should fork gnome-session, gnome-settings-daemon and mutter, to be rid of those frequent issues. They're still stuck at support for
mutter <= 3.28- almost two years old now - because every mutter release starting with 3.30 included major breaking changes ... But they just don't have the manpower to maintain those desktop components themselves.)TL;DR: Basically, I'm usually the first person to notice that some change from GNOME upstream breaks Pantheon, GNOME GitLab is the wrong place to report those breaking changes since they're just "features, not bugs" (so I've been told), elementaryOS is struggling to keep up to support new GNOME releases, and I'm their first line of defense, without even wanting to be in that position - and it doesn't help that bug reports for "this fedora update broke my packages" are most often ignored.
There is significant value in having only bug reports that we actually plan to work on open in downstream Bugzilla. For example, I currently have saved searches to display gnome-shell and gnome-software bugs, but only RHEL bugs, because there are too many Fedora bugs. This means that all downstream bugs are ignored. If there were only a few Fedora bugs, then I could include the Fedora bugs in my search results so that real downstream issues wouldn't be ignored.
That said, reporting the issues upstream, in addition to downstream, would be a significant improvement over the status quo. But the downstream bug is really negative value. The only Fedora processes that I'm aware of that require downstream bug reports are the blocker, FE, and PrioritizedBug processes, and those I've already stated would remain open downstream. (E.g. our script for closing bugs could look for the relevant keywords and avoid closing bugs that are proposed/accepted blocker/FE or PriorizitedBug.)
This is not true. It's important to note that downstream bugs are the inputs for the characterization processes (PrioritizedBug, BlockerBug, FreezeException). If the bug doesn't exist in the first place, there's no way for that to be tagged for those processes.
Essentially, you cannot be auto-closing bugs (or worse, not even filing them) downstream without breaking how we even do distro development.
Metadata Update from @ngompa:
Metadata Update from @ngompa:
If you want a bug to block the release, you'll need to create it and link to an upstream bug report instead of finding an existing downstream bug report to use for the purpose, but this does not seem so hard.
This proposal is primarily intended for maintainers who are currently ignoring downstream Bugzilla. I don't see how it would break workflows. If you currently read downstream bugs, obviously you would probably not want to auto-close bugs for your packages.
Metadata Update from @catanzaro:
Metadata Update from @catanzaro:
(Created https://pagure.io/pagure/issue/4749 for our fun with the meeting-request tag)
I certainly, over the years, have been a major culprit as "Fedora maintainer ignoring hundreds of bugs assigned to them". Generally, when I'd spend a day looking at Fedora gnome-shell and mutter bugs in Red Ha bugzilla, I'd find lots of interesting and intriguing stuff, and sometimes find fixes to make upstream, but getting bugzilla anywhere close to clean would have required me to be close to full-time bugzilla triager, and not get anything else done.
Crashes
I, generally, do not think that getting ABRT to report bugs upstream is a good idea. Back in the days of "bug buddy", parts of GNOME bugzilla were a wasteland. Having automated or semi-automated bug reports mixed together with human-curated things is a not a good idea.
My feeling general feeling about the approach that would work best:
Double down on retrace.fedoraproject.org - if we think there are things that people can do manually to make a better bug report, don't do that in bugzilla, add a way to annotate/extend a crash in retrace.fedoraproject.org. Or at least, make associating with a crash in retrace.fedoraproject.org an essential part of filing a crash bug in bugzilla, and be able to find those bugs easily
Put resources into making triaging crashes on retrace.fedoraproject.org a rewarding and rewarded activity. Have guides to what you should do, collect stats, publish leaders, and make sure that it from a UI perspective doesn't feel Sisyphean - it should look good if the top 10 crashes are properly triaged, even if there is a long tail of 100 more odd stack traces that haven't been triaged.
Everything else
Somehow make part of the filing experience for GNOME components, pre-filing:
"If you do not think this is a packaging problem or other Fedora specific problem, please file it upstream"
because while automatically filing crashes upstream (or anywhere) is hard to manage, requests for UI changes, for example, are better handled upstream.
Another exception: security tracker bugs. Just got pointed to yet another security bug we had ignored. Currently they get ignored along with everything else. If we could turn off the fire hose, maybe these wouldn't slip by....
We know ABRT reports to Red Hat Bugzilla work quite well, though (at least up until it started marking everything as private and intentionally reporting duplicate issues for private bugs, both solvable problems).
I think the problem with Bug Buddy was simply that Bug Buddy would file dozens upon dozens of duplicate reports for the same issue. ABRT is basically already smart enough to not do this; it just needs to trust its own heuristics a bit more and more aggressively assume bugs with similar-looking backtraces are probably duplicates rather than opening a new bug and marking it as a "Possible Duplicate" for a human to review. Having high-quality crash reports in the main project issue tracker seems extremely valuable. I don't think the situation is comparable to Bug Buddy.
Although I agree with your suggestions for retrace.fedoraproject.org, I think we'd need further planning to determine a path towards making it useful for upstream developers who don't use Fedora and are not interested in downstream tooling.
This involves a few elements: retrace, GNOME gitlab, RHBZ, Fedora QA, ABRT devs. But what is the WG role? Are there UX choices that the WG should have a say in? Is this ready for meeting time?
The WG certainly has a say in how we handle bugs for desktop packages. I think we're ready for meeting time.
ABRT is basically a separate issue. Ernestas has already indicated interest in reporting directly to GNOME GitLab, should we decide that's what we want to do.
And this has basically nothing to do with Fedora QA. I'd say any bug that's important enough for Fedora QA to take interest can continue to be tracked downstream. We don't have to close everything. The goal is to just reduce the size of the firehose.
I'm following this issue in Pagure, but if I can provide any help as Program Manager, please feel free to pull me in to meetings or ping me here or via email.
Metadata Update from @chrismurphy:
So we've agreed the GNOME packages are in bad shape in Red Hat Bugzilla, and we should probably not leave them like this. We don't have consensus on how to handle the situation.
Metadata Update from @chrismurphy:
As a first and trivial step, maybe ask users to file bugs in upstream bugzilla:
"
Please report bugs in https://bugzilla.gnome.org/...?component=foobar"
GNOME stuck a knife into its Bugzilla instance, so you have to figure out where in their GitLab each component is.
I'm sure the majority of components can be found in https://gitlab.gnome.org/gnome/foobar
https://gitlab.gnome.org/GNOME//issues
An officially maintained mapping would be a pre-requisite for this. If there isn't one, then this will not be great.
I'd think that it'd be enough if the maintainers would just verify the URL when changing it. It's a one time thing.
By the way, tools such as ABRT could be capable of handling appstream files. In these, the
<url type="bugtracker">node is set by upstream. https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-urlThe new service Packager Dashboard illustrates the problem here quite nicely.
This is one of these reoccurring issues that goes back more than a decade ( we discussed this same issue in QA when James Laska was there ) the solution we came up with to be the best way to address this was to extend RHBZ to be able to communicate with upstream BZ then downstream package maintainers could just "forward" the report upstream once they had triage it if relevant.
That idea was shutdown by RHBZ maintainers at that time due to mainly security concerns ( if I can recall correctly ) because RHEL ( and thus it's customers ) shared the issue tracker with Fedora.
I personally have administrated an issue tracker ( jira ) in which we where doing exactly that for over 1000 projects ( not exactly the size of Fedora but measurable never the less and granted between jira instances but basically you are just sending mail between those instances ) with no problems so this problem can most certainly be solved on a technical level and tailored to each projects workflow for that matter however that solution does require Fedora to gain it's own issue tracker for the project separated from RH and thus can be tailored to the projects needs and not be a security risk to RH customer base and b) bear in mind this does not mean the issue has been resolved as in you still need to have enough resources ( manpower ) on the receiving end to address the issue so if a project is already starved of resources it does not matter where it's issue resides.
What has change since back in those days is that reporters by large, regardless of distribution have started to file reports directly upstream if the project resides on github due github currently being the largest social development platform on the planet so Gnome might want to consider switching the roles for it's repositories as in Gitlab becomes the mirror while Github becomes the primary which could to a certain extent solve this problem while also attract new people and contribution to the project.
I probably will get flamed for saying this but arguably Fedora as a project should do exactly the same thing, stop this outdated nonsense of having to run it's own infrastructure on self made and coupled together solution that never quite work out or gain popularity and cost tremendous resources ( and money for RH ) and move itself closer to where people ( and upstream ) actually are and I strongly recommend that the leaders of the project along with relevant parties high enough within RH sit down and have a serious discussion about doing this for the long term sake of the project.
If we want different results, we have to try different approaches. It's that simple.
Last time we discussed this, we agreed we could do a small trial with a few GNOME packages to see how it goes, but no more than that. Now ABRT developers have actually implemented this feature. I've volunteered epiphany and glib-networking packages to begin this trial, and Ray has volunteered gdm and accountsservice. This isn't really going to be a terribly interesting trial to start with, because these packages have almost no ABRT reports from the past couple years, but that's because ABRT has been in such bad shape that reporting almost always failed (#130) even prior to #156. But it should be a very low-risk way to start experimenting with upstream reporting.
FYI: tpopela determined we had 33 unresolved desktop security bugs in Fedora, which had been ignored by the Bugzilla assignees. Many of these are 2+ years old. I've closed most of them just now, except for a couple that haven't yet been handled by upstream rebases. But this was all one-time work: we have no way to track such problems going forward.
@catanzaro the list that you got was probably a half of what it was last week before I (and others including you) cleaned them as well. So it was probably 60+.
So I managed to get the original list and it was 115 security bugs (not all include all the GNOME packages, there was Qt, grub2, ..).
We discussed this issue during today's WG meeting. @tpopela has a plan to assign GNOME packages to a mailing list, and to add a comment to Bugzilla pages for those packages, suggesting that people file issues upstream.
There's more to it than that, and the WG was in favour overall.
It would be good to check in on this issue in a couple of months, if there's no progress by that time.
Metadata Update from @aday:
Metadata Update from @aday:
As agreed at today's WG meeting, this issue isn't tied to a particular release, so we can drop th milestone.
Metadata Update from @aday:
Metadata Update from @catanzaro:
Tomas gave an update on this today. Sounds like it is progressing well.
Metadata Update from @catanzaro:
This is more or less stalled right now, because of:
a) limitations of Pagure and the way how it handles groups - especially https://pagure.io/pagure/issue/5330 - without this resolved only admins can change some project settings and not members of the group that is listed as admin group. I don't have any hopes that this will be fixed in Pagure and I don't know whether Fedora will move away from Pagure.
b) the open question whether Fedora will stay will Bugzilla or will move to something else.
Let's do the best we can without requiring any changes in Pagure or Bugzilla. We can still set up an autoreply bot to tell bug reporters to consider moving their bug report upstream, right?
We spoke about this issue at yesterday's working group meeting. @tpopela is still working on the plan for this issue.
We agreed that it would be good to introduce the changes for a subset of packages first - perhaps just the modules that are hosted on gitlab.gnome.org
We will do this in stages and for the first one we will create a BRE (Bugzilla Rule - i.e. https://bugzilla.redhat.com/page.cgi?id=ruleengine/details/index.html&rule_name=Fedora%20auto-set%20mirror%2B%20for%20specific%20kernel%20subcomponents) that will automatically add the following comment to the components that we will pick:
We will start only with gnome-shell component (@fmuellner) and then extend it to more once we will see that things are working in a way that we've planned. We will also add this comment to all already opened bugs against gnome-shell. The tricky part is the maintenance of the BRE as one is only able to add or maintain rules if part of the Program Management Bugzilla group, but neither me or @mattdm are. I've talked to Brendan Conoboy and he will create the rule for us and will maintain it for us as well. If that job will be too demanding, then we've talked about the possibility of adding me to the Program Management group for the Fedora product in Bugzilla.
Nit: in the last sentence, I would add another comma: "add a link here, and close this issue"
Or it might be clearer if we broke the sentence down into bullets:
I will incorporate the @aday 's suggestion
Are there plans to also suggest something to users of ABRT, so their bug reports won't rot in Fedora's infrastructure?
@genodeftest If you mean the bugs created through ABRT (i.e. https://bugzilla.redhat.com/show_bug.cgi?id=2214808), then yes. If you mean even the cases without Bugzilla bug, then no.
Any status update on this?
No, I've stopped any work on this as the Red Hat's PgM team was heavily impacted by the layoffs just few days after the new path forward was scheduled and I didn't want to add more stuff on their plate as in the beginning I will need a not trivial amount of assistance to set up the BRE. Things are getting slowly back to normal, so I think that I can revisit this in few weeks.
@tpopela you posted a plan in https://pagure.io/fedora-workstation/issue/131#comment-861407 to implement a Bugzilla rule for gnome-shell at first, which we would test for a little while before expanding to the rest of the GNOME components. But I don't think it has been implemented yet. Any further status updates?
It seems like we're quite close to having a working solution to this longstanding problem. Would be good to cross the finish line.
The RH's PgM team is slowly returning back to normal state so I might indeed look into this again.
Why does this have anything to do with the program management team? Is nobody else able to edit Bugzilla rules? Surely the Bugzilla developers can help with that?
Exactly, please read https://pagure.io/fedora-workstation/issue/131#comment-861407 again.
I don't think so. It's all or nothing situation.
The Bugzilla Rule was created - https://bugzilla.redhat.com/page.cgi?id=ruleengine/details/index.html&rule_name=Further%20Upstream%20First%3A%20GNOME - but it wasn't activated yet.
The rule is live and here is how it looks in action - https://bugzilla.redhat.com/show_bug.cgi?id=2250870.
I'm now working with @kalev (he's owner of the gnome-sig mailing list) to create a new e-mail alias and bugzilla account for gnome-sig-untriaged@fedoraproject.org which will be an alias for existing gnome-sig@fedoraproject.org
To me, that only sounds like it hasn't been triaged yet (but hopefully will be in the future). I don't have a better suggestion at this moment, though.
I agree ,but we didn't come up with a better name in the past and finally decided to proceed with this one. But it will definitely be better than the current status quo.
I would call it gnome-sig-unassigned@ but gnome-sig-untriaged@ is a lot better than the status quo. Thank you!
I just received my first automated comment containing:
I think a third use case could be added - when users want to request that an existing fix/patch/new version is pulled into Fedora. Or perhaps the first point can be expanded with this. While some might argue that backporting a fix is included in "related to packaging", I think an explicit mention would make it clearer.
Also, I noticed that the bug reporter receives a needinfo from the script. I understand the motivation (remind the user if no action is taken), but I worry whether this is too aggressive. Currently it seems that RH Bugzilla sends "Your Outstanding Requests" notification every 3 days, repeatedly. If the user wants to keep the bug open, because it's legitimate according to the stated use cases, they have nothing to reply but at the same time they need to figure out how to cancel the needinfo, which some users might struggle to figure out. Also, for people like me who regularly report gnome bugs to RHBZ for various reasons, this is an extra annoyance, because after filing the bug, I'll need to wait for the bot to trigger, and then I'll need to go back to the bug and cancel the needinfo on me, every single time. I'll manage, but I wonder if the needinfo should be kept or not.
What you're mentioning is definitely part of first option as requesting a backport is related to the Fedora packaging from my POV.
I should have mentioned it before, but it was not our requirement to set the needinfo (see no mention of it in https://pagure.io/fedora-workstation/issue/131#comment-861407). It's just an implementation detail of the Bugzilla Rule that was picked up by @blc who was helping us to set the rule. It's there to avoid infinite loops of comments (as of now the rule engine will stop to add new comments when needinfo is set on the reporter). There was another option - moving bug from NEW to ASSIGNED, but I told Brendan that we shouldn't go this was, because that means that the bug was triaged (and would be strange to have the assignee set to gnome-sig-untriaged and bug in ASSIGNED). If we will come up with another way how to avoid these infinite loops, then we can remove the needinfo.
I'd say it's clear enough that a request to update a package is a packaging issue. But of course it wouldn't hurt to clarify the text further.
Regarding needinfo?, perhaps the use of needinfo? was too aggressive. I guess we can use anything else to indicate the bug has been touched by the script already. There is an AutomationTriaged keyword that already exists; can we simply add that keyword?
Will you come up with something? :)
Nice find! @blc could we use that instead?
OK. But it wasn't clear to me :-) Packaging was equal to spec file adjustments (Requires, etc) in my head. But we can wait whether more people get confused, if you don't want to make the text overly long.
So what will happen when I cancel that needinfo (because it's a legitimate bug), will it post the comment again and needinfo me again? That would obviously be a broken process.
+1 to using a different detection algorithm anyway.
Another option could be to check whether there is already some comment from
fedora-admin-xmlrpc@fedoraproject.org. But that would break if more than 1 rule wanted to comment in the same bug report.The rule has been updated so it doesn't use needinfo, but keyword instead, thanks @blc !
Also, gnome-initial-setup had a bug that made the a11y menu to not show. This menu was absence in Fedora 37 and 38, despite of the issue being reported: https://bugzilla.redhat.com/show_bug.cgi?id=2155120
@tpopela could you provide a status update please? It would be nice to expand this rule to a larger set of GNOME packages.
So the rule - https://bugzilla.redhat.com/page.cgi?id=ruleengine%2Fdetails%2Findex.html&rule_name=Further%20Upstream%20First%3A%20GNOME - has been in place for 2 months and during that time it acted on 488+ bugs[0]. Out of these 385 were bugs reported by ABRT[1] so that leaves us with 107[2] bugs that were reported by people. Out of these only 9 were closed as CLOSED/UPSTREAM[3]. I think that we do have a problem with people not following bugs after they open them.
[0] - https://bugzilla.redhat.com/buglist.cgi?columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&f1=rh_rule&f2=rh_rule&f3=rh_rule&j_top=AND_G&list_id=13404968&o1=changedafter&o2=changedto&order=status%2C%20assigned_to%2C%20id%2C%20&query_format=advanced&v2=Further%20Upstream%20First%3A%20GNOME
[1] - https://bugzilla.redhat.com/buglist.cgi?columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&f1=rh_rule&f2=rh_rule&f3=rh_rule&f4=rh_rule&j_top=AND_G&o1=changedafter&o2=changedto&order=status%2C%20assigned_to%2C%20id%2C%20&query_format=advanced&short_desc=%5Babrt%5D&short_desc_type=allwordssubstr&v2=Further%20Upstream%20First%3A%20GNOME
[2] - https://bugzilla.redhat.com/buglist.cgi?columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&f1=rh_rule&f2=rh_rule&f3=rh_rule&f4=rh_rule&f5=rh_rule&j_top=AND_G&list_id=13405667&o1=changedafter&o2=changedto&order=status%2C%20assigned_to%2C%20id%2C%20&query_format=advanced&short_desc=.%2Aabrt.%2A&short_desc_type=notregexp&v2=Further%20Upstream%20First%3A%20GNOME
[3] - https://bugzilla.redhat.com/buglist.cgi?bug_status=CLOSED&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&f1=rh_rule&f2=rh_rule&f3=rh_rule&f4=rh_rule&f5=rh_rule&f6=rh_rule&j_top=AND_G&list_id=13405669&o1=changedafter&o2=changedto&order=status%2C%20assigned_to%2C%20id%2C%20&query_format=advanced&resolution=UPSTREAM&short_desc=.%2Aabrt.%2A&short_desc_type=notregexp&v2=Further%20Upstream%20First%3A%20GNOME
I'm OK with this because my goal is to give users an opportunity to follow up, not to force them to.
Still, we could do a little more:
I wouldn't necessarily treat ABRT bugs any differently than other bug reports. ABRT needs to learn to report bugs directly to upstream, but since that's not likely to happen soon, users will have to do it.
Maybe they are not motivated to create yet another account on yet another platform they are unfamiliar with? (I'm thinking of people rather the opposite of FOSS developers)
When trying to understand that situation I would be left rather frustrated I guess: Having provided some information just to get told something like "We're not in charge, please go to GNOME gitlab instead"
Maybe it would help them to automate the second step reporting to GNOME's gitlab? (I guess that would be rather hard to implement though, at least if it should be done nicely, avoiding too many duplicates …)
Or maybe it would help them if ABRT reported directly to GNOME's gitlab if the app is on your predefined list? (This would not solve the issue of yet another account though…)
To approach the issue of yet another account: Would it be possible to have Fedora accounts be accepted on GNOME Gitlab (besides GitHub and Google accounts)?
I don't think we can safely automate this.
Yes, this would be desirable (but is not likely).
I don't know. Also, note that a Fedora account is just one way to log into Red Hat Bugzilla. I suspect most people create Bugzilla accounts directly.
Also the bug reporter needs to be present in the issue to respond to questions.
Not great for legitimate downstream bugs and for people not familiar with cancelling needinfo. See my recent feedback.
This is even worse. Automatically closing proposed blockers would be terrible. And it wouldn't make anything better. If people didn't read the bot comment, they wouldn't read the close notification either.
I looked at some of those bugs linked in [2] (above) and some of them are a year or two old. No wonder people don't feel motivated to re-file them, I wouldn't either. I think a better statistic would be to only count bugs created after the bot has been put to action. But when I looked at some of the newest bugs, yes, it seems that many people just ignore the bot and don't forward it upstream, it's true. I think that asking politely is the best thing we can do (even better might be to ask the users before they spend their time to file it to RHBZ), attempts to force users won't help and just complicate things.
That's what was implemented in the beginning and some (including Kamil) didn't like it
I think that this is too much and not anything that I would like to see even myself.
Ah! That's not supposed to be. I somehow remembered that it's only acting on newly opened bugs, but that's not true. It will add comment if any of the applicable bugs is updated. Let me fix the text and queries:
So the rule - https://bugzilla.redhat.com/page.cgi?id=ruleengine%2Fdetails%2Findex.html&rule_name=Further%20Upstream%20First%3A%20GNOME - has been in place for 2 months and during that time it acted on 67+ bugs[0]. Out of these 55 were bugs reported by ABRT[1] so that leaves us with 12[2] bugs that were reported by people. Out of these only 1 was closed as CLOSED/UPSTREAM[3].
[0] - https://bugzilla.redhat.com/buglist.cgi?chfield=%5BBug%20creation%5D&chfieldfrom=2023-11-20&chfieldto=Now&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&f1=rh_rule&f2=rh_rule&f3=rh_rule&f4=rh_rule&j_top=AND_G&list_id=13406259&o1=changedafter&o2=changedto&order=status%2C%20assigned_to%2C%20id%2C%20&query_format=advanced&v2=Further%20Upstream%20First%3A%20GNOME
[1] - https://bugzilla.redhat.com/buglist.cgi?chfield=%5BBug%20creation%5D&chfieldfrom=2023-11-20&chfieldto=Now&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&f1=rh_rule&f2=rh_rule&f3=rh_rule&f4=rh_rule&f5=rh_rule&j_top=AND_G&list_id=13406262&o1=changedafter&o2=changedto&order=status%2C%20assigned_to%2C%20id%2C%20&query_format=advanced&short_desc=%5Babrt%5D&short_desc_type=allwordssubstr&v2=Further%20Upstream%20First%3A%20GNOME
[2] - https://bugzilla.redhat.com/buglist.cgi?chfield=%5BBug%20creation%5D&chfieldfrom=2023-11-20&chfieldto=Now&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&f1=rh_rule&f2=rh_rule&f3=rh_rule&f4=rh_rule&f5=rh_rule&f6=rh_rule&j_top=AND_G&list_id=13406263&o1=changedafter&o2=changedto&order=status%2C%20assigned_to%2C%20id%2C%20&query_format=advanced&short_desc=.%2Aabrt.%2A&short_desc_type=notregexp&v2=Further%20Upstream%20First%3A%20GNOME
[3] - https://bugzilla.redhat.com/buglist.cgi?bug_status=CLOSED&chfield=%5BBug%20creation%5D&chfieldfrom=2023-11-20&chfieldto=Now&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&f1=rh_rule&f2=rh_rule&f3=rh_rule&f4=rh_rule&f5=rh_rule&f6=rh_rule&f7=rh_rule&j_top=AND_G&list_id=13406264&o1=changedafter&o2=changedto&order=status%2C%20assigned_to%2C%20id%2C%20&query_format=advanced&resolution=UPSTREAM&short_desc=.%2Aabrt.%2A&short_desc_type=notregexp&v2=Further%20Upstream%20First%3A%20GNOME
And unfortunately that bug has a broken link to gnome gitlab, because it turns out that bugzilla UI is too unfriendly for regular people to use :-( Providing just the bug ID without a component creates an invalid gnome gitlab link, unfortunately. We'll see if this a regular occurrence for reporters.
The valid bugs were created by 8 different people, who didn't forward the bug upstream. It might be worth a try to ask them why they didn't follow the advice. Perhaps a stronger wording explaining that the bugs will really not get resolved in RHBZ would help. Or perhaps the overall reason is something else, we just don't know.
Proposal: just use slightly stronger wording.
"This component is maintained by the GNOME project. Bug reports on Red Hat Bugzilla are not actively monitored. Please consider reporting your issue directly to GNOME at https://gitlab.gnome.org/GNOME/ to improve the chances that your issue will be resolved."
So yesterday we we've touched this issue a little bit on the meeting and we will extend the current solution to more packages that gnome-sig owns. I've made a quick query looking at the packages that gnome-sig co-maintains (but we're interested only in those where gnome-sig is admin) - https://src.fedoraproject.org/group/gnome-sig - and created a report with opened bugs and looking at the TOP15 from there:
gnome-shell 408
gnome-control-center 128 (default BZ assignee gnome-sig@)
nautilus 121 (default BZ assignee mclasen)
xdg-desktop-portal-gnome 59 (default BZ assignee amigadave)
mutter 54 (default BZ assignee fmuellner )
gnome-settings-daemon 52 (default BZ assignee kalev)
tracker-miners 48 (default BZ assignee kalev)
gvfs 47 (default BZ assignee oholy)
NetworkManager 44 (default BZ assignee lkundrak)
gnome-software 42 (default BZ assignee mcrha)
gdm 35 (default BZ assignee rstrode)
xdg-desktop-portal 30 (default BZ assignee amigadave)
gnome-boxes 27 (default BZ assignee teuf )
totem 27 (default BZ assignee gnome-sig@)
gjs 26 (default BZ assignee walters )
We can remove gnome-shell from that list as it has already been handled and also NetworkManager. Then we have a component that is not under the GNOME's GitLab (xdg-desktop-portal) so the current rule won't fit (as we hard code a link to GNOME's GitLab). I would also remove gnome-software from that list as it does have an active maintainer. And we should actually move gjs from @walters. @mclasen @kalev @amigadave @oholy @rstrode @teuf (I will mention @feborges here as well) - do you agree with moving the BZ default assignee to gnome-sig and to add automatic comment (by exexuting the following Bugzilla rule - https://bugzilla.redhat.com/page.cgi?id=ruleengine%2Fdetails%2Findex.html&rule_name=Further%20Upstream%20First%3A%20GNOME) when new bug is opened/existing bug modified asking the report to consider reporting the issue upstream?
I agree, thanks.
Please go ahead for my packages. Thanks!
I'm going to move the following packages today:
gnome-control-center 128 (default BZ assignee gnome-sig@)
nautilus 121 (default BZ assignee mclasen)
mutter 54 (default BZ assignee fmuellner )
gnome-settings-daemon 52 (default BZ assignee kalev)
tracker-miners 48 (default BZ assignee kalev)
gvfs 47 (default BZ assignee oholy)
totem 27 (default BZ assignee gnome-sig@)
And also work with Colin on getting gjs away from him.
All components including from he previous comment including gjs were handled yesteday and https://bugzilla.redhat.com/page.cgi?id=ruleengine%2Fdetails%2Findex.html&rule_name=Further%20Upstream%20First%3A%20GNOME was updated.
This project seems to be going well in my opinion. Can we move the remaining packages?
I don't have time to migrate everything at once, so I will continue doing it in batches. So the next batch could contain:
gnome-connections 27 (default BZ assignee mkasik)
PackageKit - skipping as it's not in GNOME's GitLab
gnome-terminal 26 (default BZ assignee mclasen)
evince 25 (default BZ assignee mkasik)
gnome-text-editor 24 (default BZ assignee linkdupont)
flatpak- skipping as it's not in GNOME's GitLab
xdg-desktop-portal-gtk- skipping as it's not in GNOME's GitLab
gnome-calendar 21 (default BZ assignee gnome-sig)
gnome-online-accounts 21 (default BZ assignee limb)
gtk3 20 (default BZ assignee mclasen)
gnome-session 18 (default BZ assignee rstrode)
gnome-disk-utility 18 (default BZ assignee amigadave)
seahorse 16 (default BZ assignee mclasen)
plymouth 16 (default BZ assignee rstrode)
@mkasik @mclasen @linkdupont @limb @rstrode @amigadave do you agree with moving the BZ default assignee to gnome-sig and to add automatic comment (by exexuting the following Bugzilla rule - https://bugzilla.redhat.com/page.cgi?id=ruleengine%2Fdetails%2Findex.html&rule_name=Further%20Upstream%20First%3A%20GNOME) when new bug is opened/existing bug modified asking the report to consider reporting the issue upstream?
I agree with migrating of evince and gnome-connections to gnome-sig.
+1 for gnome-online-accounts
Can we please reword the boilerplate message?
This is not accurate and misleading. GNOME does not maintain Fedora packages.
@ngompa "This component is maintained by the GNOME project members" ? Or do you have any better suggestion?
"This component is maintained by members of the GNOME community that prefer issues to be reported directly to GNOME at
https://gitlab.gnome.org/GNOME/<component>""Bug reports for this component on Red Hat Bugzilla are not actively monitored. Please consider reporting your issue directly to GNOME at https://gitlab.gnome.org/GNOME/ to improve the chances that your issue will be resolved."
sorry for dropping the ball on this, but I've asked Brendan to update the BRE with the suggestion from @catanzaro . And I've also asked him to add gnome-connections, evince, gnome-calendar, gnome-online-accounts, gtk3, gnome-session, gnome-disk-utility, seahorse and plymouth to the list of components that are triggering the rule.
I'm still waiting on the response from @linkdupont about gnome-text-editor.
My plan is to get this over the finish line in the following weeks.
Plymouth is not a GNOME component, please don't add it there.
@ngompa right! thank you for spotting it!
Oh my gosh. I had no idea you were waiting on a reply from me. I must have missed the original mention. Sorry! I am in favor of changing the default assignee of gnome-text-editor to gnome-sig.
@linkdupont no this was not blocked by you, don't worry :) but thank you for letting me know!
This activity is currently on hold until the future of Fedora's issue tracker is figured out (probably Forjejo) and our possibilities there identified.
Metadata Update from @catanzaro:
FESCo says we have to remove the sentence: "Bug reports for this component on Red Hat Bugzilla are not actively monitored." Seems like a shame, because that means the autoresponder will be worse at setting expectations.
@tpopela can we update the autoresponder?
@catanzaro, may I know why the string needs to be removed? (I think it's helpful.)
Oops, I forgot to link to the FESCo ticket.
My $0.02: the package maintainer responsibilities are unrealistic, and it'd be better to change those instead of making our autoresponder worse. Too bad.
I've asked Brendan to do so.
The rule is updated now.
FESCo has asked us to "explore" replacing our autoresponder with a custom issue report template. A template that says what we want to say seems clearly superior to an autoresponder, so this seems uncontroversial. We have been instructed to create a bug report against the Bugzilla product in Red Hat Bugzilla to request this. I've also requested that the autoresponder be immediately removed in #475 as it's independently necessary to resolve that issue.
One problem I'm not sure what to do about will be syncing the set of packages that use the template when packages get added or removed from gnome-sig.
Is it? From the FESCO issue I can only see the request the remove the first sentence which we've done already last week.
They have requested that we switch to an issue report template. Surely there is no further need for the autoresponder if we add a template? Users will read the same message, but before they waste time reporting the bug in the wrong place, rather than afterwards.
Who will add those templates? Do you have any ETA? I agree that once the templates are figured out and in place, then the BRE rule won't be needed.
Request to add template
Um, notably the autoresponder runs when a bug report changes component, whereas the issue report template does not. So maybe we could keep the autoresponder and just change it to run when component changes rather than when a bug is created.
That would also resolve #475.
In #475 we have a proposal to change the autoresponder such that it comments only when a component is changed.
We have an issue report template now. Only the Bugzilla admins can edit the template, but anybody in the fedora_pm Bugzilla group can apply or unapply the template to a component. So next step is to ask a somebody in fedora_pm group to apply the template to the same components that previously used the autoresponder.
I think that set of components was much too small. I'd like to change the Bugzilla assignee of all GNOME components to @gnome-sig, and apply the template to all such components, with only a few exceptions for components where we know a particular human will handle the issue reports, like Milan's packages.
Even if that happens, the respective Fedora package owners are still supposed to be subscribed their own packages, right? I just want to make sure that non-upstream bugs (packaging issues, etc) are still handled and are not just sent to /dev/null.
Half of the package owners are not even active in Fedora anymore, and the other half do not read their bugmail. I think there are very few GNOME packagers monitoring Red Hat Bugzilla.
That said, perhaps if the issue report template is effective at reducing the volume of incoming bugs, we could change that. As a package owner, if I receive 5 bug reports, I'm going to be more inclined to read them than if I receive 50 bug reports in the same period.
We should find an answer to this problem. When package maintainers don't respond even to genuine packaging issues, the whole Fedora user experience suffers. We might have a chance to re-design the system from scratch when leaving Bugzilla, and we really should try. But until that happens, let's not completely drop the ball. For example, if there are at least a couple of people subscribed to that gnome-sig mailing list, who watch over the incoming reports and ping a relevant person if something appears to be a packaging/Fedora-specific problem at a glance, that's still at least something. Better than sending the reports to a black hole.