How to file a bug?

Hi everyone,
I’m new to Fedora but have quiet some experience with other Linux distros /communities. And here comes the story of my first bug in this community.

More then three weeks ago I filed a bug since a combination of golang packages can not be installed on Fedora 36 anymore. See 2109630 – Can not install the components golang-github-prometheus-common-devel and golang-github-prometheus-common-promlog-devel the same time

But no reaction on this since then. No request for more details, no thanks for the bug or whatever.

So I start to ask myself, was this the right way to report the issue?
Can somebody tell me what I did wrong, or if this is just the normal way this community handles this?

Thanks for your thoughts
Imker

2 Likes

It really varies by the package maintainer. Some are very quick to reply to Bugzilla reports, others aren’t. We get 10–20k bug reports per release, so unfortunately there’s not a great way to keep on top of things at a project-wide level. (I wish there were!)

I’m not familiar with packaging in the go ecosystem, but I at least have found a clue. I updated the bug and requested more info from the person who did the builds. Hopefully this helps. I’m sorry I don’t have a better general solution for you.

4 Likes

To add to what Ben notes: reporting the bug is the right thing to do, but yes, it varies by maintainer. Most of us maintainers are volunteers, so all of our Fedora work is done in whatever time we can find after work etc. Depending on how many packages we maintain and how much time we have to work on them, this often means that we prioritise certain tasks over others.

There are also cases where package maintainers may no longer be active (things happen, lives change, one may no longer be able to find time to volunteer). For the package you’ve filed the bug against, for example, it seems like neither of the listed maintainers are active (Note that I haven’t looked to see whether the package admins are generally active—I only checked the commits to see if they’ve been active for this package) I only see commits from others (who are likely to be members of the go-sig):

https://src.fedoraproject.org/rpms/golang-github-prometheus-common

https://src.fedoraproject.org/group/go-sig

While the go-sig do look after the package, they are 32 members that collectively look after > 2000 packages, so one cannot expect them to respond to all bugs that are filed. The lack of active primary maintainers in this case is why you’ve not had any response on the bug.

There are policies in place for inactive maintainers:

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

Also for packages that fail to build from source (FTBFS) or fail to install (FTI), but I don’t think either applies to this particular case:

https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

If you could help with maintaining this package, that would be great. I expect it’ll continue to live in Fedora because the go-sig looks after new versions and so on, but bugs etc. won’t get the necessary responses if it doesn’t have active primary maintainers.

https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/

3 Likes

Thanks for your replies.

So I went is the right way, I just had bad luck that golang packages are maintained by a small group. I really understand that issue. I also know that most of us (me as well) do OSS work in spare or free time.

But from a users perspective the worst thing after bad user experience is bad communication. There are also people that would argue “You can sell the most buggy crap, you just need good communication”. I’m sure everybody has a company or two in mid that act like that…

So, if you get 20 000 bugs per release this is bad.
But if you are not able to communicate with the bug reporters, you will loose “good users” that want to help you to get a better System because of frustration. Since writing a bug report also takes time.

As a developer my own, I know it’s a lot more fun to write code than to comment bugs. But if you want to have and keep users for your software you need to keep them satisfied. And communication is a big part of this.

By the way: I don’t have a problem with this specific bug and that there is no solution for it right now. I know this might takes time, and there are maybe higher prior things to do. I guess all developers know that.

Just my thoughts
Imker

Believe me , you’re not telling us anything we don’t already know. But it’s very easy to say what should be done and much harder to find the people to do it. Telling people who are already volunteering their time “you’re not doing enough” is not going to help the situation; it will just drive away more maintainers.

2 Likes

First, how did you found the way to report the bug? I remember that my first time experience was not really easy, and that was way before GitHub took UX seriously.

I believe Bugzilla is a RedHat decision, not a community decision. Bugzilla is not helping to communicate better than it was 20? years ago. It doesn’t provide a common REST API to transform a list like this https://bugzilla.redhat.com/buglist.cgi?component=golang-github-prometheus-common&list_id=12846537&product=Fedora into something that can be displayed on package page golang-github-prometheus-common - Fedora Packages (even if it just a counter). Doesn’t have markup, links to sources, doesn’t backlink to the package page and sources. I don’t see that it helps to reward the maintainer for their work in any way. Being it a recognition, likes, funding or just listing the team that does the works. People are not aware that they can submit tests to catch problems to make the job of maintainers easier. Because Bugzilla is not integrated with Ci/CD either. You don’t see where the tests are. How many people have contributed. If maintainer are anybody your company, or maybe a friend of a friend from another company. This kind of stuff could make the process much more interesting, but that’s just dreams.

I appreciate Ben explaining and protecting maintainers. I appreciate you being involved enough into the problem to get into the discussion. I am not sure however, how to make it better. I believe RedHat did a lot already, throwing a big lump of money into Fedora monthly, and sharing parts of its infrastructure with it. And that’s I guess is the maximum they can do.

Normally I would say that golang-github-prometheus-common is a enterprise package that nobody needs to use in their free time, but being jobless, and trying to patch different projects here and there just to get a chance to earn some money, now I would say - that’s not the case. So I wouldn’t recommend you going up to your company and saying - here is what can we do to Fedora to enhance our daily lives and help the maintainers that provide convenient infrastructure we rely upon. Because I don’t have a company that backs me up, and I assume you don’t have either.

Sorry if that’s sounds too dramatic. I can just end it with saying that processes and infrastructure that exist is the best effort made so far given the budget and ability of people to participate. Some things like improving contributors experience are so behemoth to implement, that RedHat budget alone won’t probably cover it without participation from contributors themselves.

Just an opinion.

@ abitrolly
Well, since I’m a OSS dev on my own (even if not in the RedHat universe up to recently), I know that there must be a public bug tracker for the fedora project. So I searched for it

To your other points about the Bugzilla Features, well I’m with you that there are a lot issue tracking systems out there that work a lot better for most projects. But, if Bugzilla is the tool the project uses, then I would expect the maintainers to use it. Even if it feels like time travel to use Bugzilla, it would still be possible to comment the bug :wink:

To your points about company driven or not. I don’t think that this should have an effect here. It’s a package that is shipped within the default package source. So at least installing should just work for the lifetime of this Fedora version.
And I have to say, I did the GitHub - imker25/samba_exporter: A Prometheus exporter for statistic data of the samba file server. completely in my free time for three reasons:

  1. I wanted to write something useful in golang and enhance my golang skills since I don’t use them in my job
  2. I wanted to learn how Prometheus Exporters are working internally
  3. I wanted to learn how packaging the some sources for different Linux distros works

Have a nice day

What is the maintainer is not there anymore? Bugzilla doesn’t give you a chance to see it.

Well, actually the community way is to ask Fridolín Pokorný directly, but handle in Bugzilla doesn’t link to this forum, so it is unclear how to get more information about what is going on.

@ abitrolly

Yes that’s the real question. How does the Fedora Community handle it when a maintainer for a package simply has stopped working (for whatever reason)?

Btw, I just searched for Fridolín Pokorný and found the github account. According to that he is not working for RedHat anymore (https://fridex.github.io/ tells ex-Red Hatter). So that’s maybe why he does not do maintainer work for Fedora anymore?

We have this in place:

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

There are also policies to ensure packages continue to build from source and install:

https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

So, the community is quite aware that we’re volunteers and things happen which limit our time to volunteer even further, and in these cases we try to share the responsibility and when that’s not possible, drop the package.

1 Like

That’s how corporations work. Not friends. Friends are checking up on each other’s health. Giving a call “How it’s going dude…” once a while, going out to crack open a cold one (not in a gothic sense, of course).

If Bugzilla had API. it could be possible to at least see if people are not responding anymore, and give some friendly advice what to do in the issue comments.

I don’t mean Fedora is mean to maintainers. Just an observation that there is no mean number of casualties in this everlasting maintenance warfare.

I want to note here that I seem to often find that your posts fail to meet the “be excellent to each other” standards that are expected in the Fedora community. Your statement here implies that the Fedora community does not check up on each other’s health, that we don’t go “out to open a cold one”. I will not assume malice, but I will request you to please pay more attention to your posts.

See Week 0, step 3 here, for example (another link that I’ve posted above):

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

" Post to the Fedora devel list with a link to the bug report and ask if anyone knows how to contact the maintainer. CC the maintainer. Links to all other bug reports open on all neglected packages from the same maintainer should be included."

This is us checking up on each other. In most cases that I’ve seen, someone or the other is able to connect with the non-responsive maintainer and the community learns what their current situation is. Then, with them in the loop, a decision is made on what to do next.


You may have missed regular Fedora community socials and community conferences that happen regularly E.g.:

Did you read the link on FTI/FTBFS or did you look at a bug to see how the process works? It uses the Bugzilla API to file issues and include information about what is causing the issue.

Irrespective of whether it is a corporation or a community of friends, the one parameter that needs to be taken into account is the availability of resources. If the Fedora community has N human hours in total resources, it is impossible to deliver/maintain products that need more than N hours.

Packages are maintained by individuals and teams. If the individuals/teams no longer have the necessary resources to continue working on them for whatever reason it is not always possible for others to automatically just fill in—it is a reduction in the total human power available to the community.

Here’s a recent example of many community members coming together to take over packages that a maintainer could no longer maintain:

https://pagure.io/fesco/issue/2858

Here’s the recent post to the devel list informing the community of orphaned packages and how they may impact other packages in the distribution:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/CH45AJJZ6AT3GJMNGP24VWDHZMQS2XF2/#L56QE2DDR6XLBWRU4OSPUU67PSZP3BAO

You will again see that many package maintainers step up to absorb these packages.

You message implies that Fedora community checks up on each other’s health, and while you did provide argumentation and links to policy that instruct people to do this, there is no hard evidence that this what the community does. While I implicitly appreciate all answers and links that people give because they spend they time bothering, you are also giving me advice to pay more attention to my posts, which implies that you do not want me to write my posts. I will assume no malice, but this advice can be as well read as “please shut up” (no offense implied - it is just an example). If these messages doesn’t carry any offense to you, why are you consistently implying that they affect somebody else?

This is us checking up on each other. In most cases that I’ve seen, someone or the other is able to connect with the non-responsive maintainer and the community learns what their current situation is. Then, with them in the loop, a decision is made on what to do next.

I don’t read policies, because it is hard for me to follow the language, but this one is actually a good thing.

You may have missed regular Fedora community socials and community conferences that happen regularly

I am in Belarus, and RedHat banned my account, along with UpWork, and most of my friends have left the country, because of the war sanctions. One day I will recover, find a job, and will be less frequent on this forum (if at all). The frustration that things are not ideal and going for the worse is real. No intention to ruin anyone spirits. There is nothing that can be helped. Just feel that I need to explain myself.

I looked at the bug 2109630 – Can not install the components golang-github-prometheus-common-devel and golang-github-prometheus-common-promlog-devel the same time Where the person complained that nobody replies, and then somebody from this forum replied. Maybe there is a policy, and the policy is good, but my concern is that the process doesn’t work if people pop up here frustrated. I mean, it takes an effort to go out in public and complain about things, because complaining doesn’t seem to be considered being excellent to each other.

Okay. I admit I am wrong, Bugzilla has a REST API https://bugzilla.redhat.com/rest/bug/2109630 and it is documented here 6.1.3. Bugs — Bugzilla 5.0.6 documentation

So the task is to get all bugs for all packages, for each bug get list of maintainers, and get bugs where there are no replies from maintainers, count days with no reply from maintainers for each bug, then group non-answered bugs by maintainer, and make a diagram. That will give a pretty evidence if anybody is MIA.

Then a separate search could be done to see if anybody tried to contact any on the missing maintainers, and what was the result. Then attach this information to the diagrams. And then there will be a real data that shows in Fedora community checks up on each other.

I understand that there is nobody to do this analysis, so in the perfect Open Source way I need to do this, because I am proposing it, and that’s why I said that DYI is literally killing me in my other post (spilling excuses now over all my posts in this forum). And because I need to respond to recruiters instead of procrastination, but find it really hard to do, the frustration over the state of things, just pours over my little brain. Maybe there should be some #drama department on the forum. Or maybe I spend too much time redditing. I don’t know.

I don’t disagree with you. In fact, I completely agree. What I want (it it doesn’t mean somebody needs to go and fetch that) is to see the metrics. What is N (human hours spent), and what is M (maintenance hours needed)?

Fedora is a great project. I want to see this problem solved, or at least fun to work with, and metrics is the absolutely necessary to make the game. It is not my goal to fill up the forum “that’s so sad” posts, or even worse “let’s be happy and not speak about this”.

Part of my arrogant insecurity comes from the fears that I want to know what will happen to me, so I want to know this reason, and statistics. Because when people are just gone missing, I assume the worst. This is how fear works in humans - it controls thoughts and focus. Even if the worst is happening, it is better to know it, because knowledge gives an ability to control the fear and coordinate to prevent it from happening to me.

That’s why I made this remark about “friends vs corporations”. In corporate world humans are resources, and the resources that are often expendable, so corporations are not interested for people to know too much about each other. In community I believe that’s different.

That’s definitely nice to see these things. The pulse that shows that project is alive is that makes people stick, learn and have fun together improving it. The only point of conflict here is that people who join the game by filling bug reports can not see these efforts. Not knowing the rules, expecting the reply and not getting it.

The policy does include a script that does this:

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

Week 0, Step 1:

Check if the non-responsive maintainer is on vacation. To see if the maintainer has been recently active on Fedora, fedora-active-user can be employed.

Week 0, Step 3:

Post to the Fedora devel list with a link to the bug report and ask if anyone knows how to contact the maintainer. CC the maintainer. Links to all other bug reports open on all neglected packages from the same maintainer should be included.


I am very very sorry for the current situation that has left a lot of us in a state of fear for different reasons. I understand the frustration and insecurity it brings. I hope things will improve for all of us.

Thanks, I followed this and created a "Non-responsive maintainer check " bug: 2125873 – Non-responsive maintainer check for golang-github-prometheus-common-devel

The journey continuous

1 Like