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

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.

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.

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

But the downstream bug is really negative value.

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.

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.

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.

Essentially, you cannot be auto-closing bugs (or worse, not even filing them) downstream without breaking how we even do distro development.

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.

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

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

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

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.

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.

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.

As a first and trivial step, maybe ask users to file bugs in upstream bugzilla:
1. add add to Description in packages:
"
Please report bugs in https://bugzilla.gnome.org/...?component=foobar"
2. change Bug URL to point to the upstream tracker.

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/<subproject>/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-url

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

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.

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.

As agreed at today's WG meeting, this issue isn't tied to a particular release, so we can drop th milestone.

Tomas gave an update on this today. Sounds like it is progressing well.

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:

This component is maintained by the GNOME project. Issues with it should be reported directly to GNOME at https://gitlab.gnome.org.

This issue should only be kept open if it:

1. Relates to Fedora packaging or integration with other Fedora components
2. Is required for Fedora release processes, such as blocker bugs and freeze exceptions

If this issue isn't needed for either of these two reasons, please:

 * create an issue with GNOME
 * add a link to the GNOME issue here
 * close this issue as CLOSED/UPSTREAM

Thank you!

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:

If this issue isn't needed for either of these two reasons, please:

 * create an issue with GNOME
 * add a link to the GNOME issue here
 * close this issue as CLOSED/UPSTREAM

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?

Why does this have anything to do with the program management team? Is nobody else able to edit Bugzilla rules?

Exactly, please read https://pagure.io/fedora-workstation/issue/131#comment-861407 again.

Surely the Bugzilla developers can help with that?

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

• The name will be “gnome-sig-untriaged” - this should give the user a hint that the bug might not get the (from the user) expected attention.
• gnome-sig-untriaged will be set it as the default bugzilla assignee for components where we won’t have anyone assigned to the package who will really take care of the package (i.e. Milan Crha and Evolution related packages, @catanzaro and WebKitGTK related packages, ..)
• If anyone from the GNOME SIG (or others) wants to work on the bug, they can assign the bug to themselves.
• Anyone can be configured to be on the default CC list for a particular component, if they wish.

• The name will be “gnome-sig-untriaged” - this should give the user a hint that the bug might not get the (from the user) expected attention.

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.

• The name will be “gnome-sig-untriaged” - this should give the user a hint that the bug might not get the (from the user) expected attention.

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:

This issue should only be kept open if it:
1. Relates to Fedora packaging or integration with other Fedora components
2. Is required for Fedora release processes, such as blocker bugs and freeze exceptions

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.

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.

What you're mentioning is definitely part of first option as requesting a backport is related to the Fedora packaging from my POV.

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.

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?

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.

Will you come up with something? :)

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?

Nice find! @blc could we use that instead?

I'd say it's clear enough that a request to update a package is a packaging issue

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.

as of now the rule engine will stop to add new comments when needinfo is set on the reporter

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.

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.

Will you come up with something? :)

1. You are asking for a Fedora packager to do something related to the Fedora packaging (e.g. update to newer version, add a patch, adjust dependencies) rather than investigate a bug

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 think that we do have a problem with people not following bugs after they open them.

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:

• Apply a needinfo? to the bug reporter, which will nag the reporter to take action; or
• Automatically close the bug, requiring the reporter to reopen the bug if desired

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.

I think that we do have a problem with people not following bugs after they open them.

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)?

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 …)

I don't think we can safely automate this.

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…)

Yes, this would be desirable (but is not likely).

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

I don't think we can safely automate this.

Also the bug reporter needs to be present in the issue to respond to questions.

• Apply a needinfo? to the bug reporter, which will nag the reporter to take action; or

Not great for legitimate downstream bugs and for people not familiar with cancelling needinfo. See my recent feedback.

• Automatically close the bug, requiring the reporter to reopen the bug if desired

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.

• Apply a needinfo? to the bug reporter, which will nag the reporter to take action; or

That's what was implemented in the beginning and some (including Kamil) didn't like it

• Automatically close the bug, requiring the reporter to reopen the bug if desired

I think that this is too much and not anything that I would like to see even myself.

I looked at some of those bugs linked in [2] (above) and some of them are a year or two old.

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

Out of these only 1 was closed as CLOSED/UPSTREAM[3].

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.

that leaves us with 12[2] bugs that were reported by people

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?

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 component is maintained by the GNOME project. Issues with it should be reported directly to GNOME at https://gitlab.gnome.org/GNOME/.

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