Is it worth contributing to the Fedora Project?

Hello,

About a year ago I reported the following bug in Fedora 42:

Since I reported this bug no progress and no discussion happened. A few days ago this bug report was automatically closed, because Fedora Linux 42 entered end-of-life (EOL) status.

About a month ago I reported a similar bug about exactly the same problem in Fedora 44:

Moreover I also contributed a pull request with possible trivial fix of this problem:

This PR was made according to fix of a very similar issue in the nfs-utils package that I reported and discussed with Steve Dickson here. Steve, thank you again!

Both bug reports regarding the glusterfs package are assigned to Benson Muite with 5 or 6 additional persons in the CC list and both of the bug reports are completely ignored. This time even a pull request is created, but it is ignored too.

The only difference now is that Kaleb KEITHLEY has removed himself from CC list of the second bug report.

With all the above in mind I’m asking a simple question now: Is it worth contributing to the Fedora Project?

I understand that some members of Fedora Project are busy. But are they so busy that an issue with a trivial solution could never be resolved, even after a ready-made solution already contributed? Is Fedora Project really a community driven project?

It is a community driven project, which is exactly why these issues happen. If were all doing this as part of our jobs, we’d have all the time in the world to focus on various Fedora things—like our packages. It’s because it’s a volunteer community project that we are constantly prioritising and reprioritising tasks, which means that low priority tasks don’t get the attention someone else (like a user) thinks they deserve—sometimes we never get to certain tasks.

When it comes to package maintenance, we’re always short of human resources. We have thousands of packages, and not enough maintainers. That really is the issue—not that people don’t care. There are also lots of times that we package maintainers take on packages that we don’t use, because a package we do use depends on it—but this does mean it’s more about keeping the dependency alive and not really looking after it.

There certainly are Red Hat people that look after packages—often packages that are of interest to Red Hat—and we are grateful for this because, these are usually critical packages that would suffer if they weren’t given the attention they need (the kernel for example).


I don’t have an answer/solution to the lack of human resources—it’s always been an issue, not just with package maintenance, but also other parts of the community—the docs/design/marketing/you name it. This is also not unique to Fedora. It’s a common characteristic of all the volunteer communities I participate in.

Automation helps, improving onboarding helps, sharing loads helps, but yeh, if there’s more work than we can collectively manage, something will remain undone.

I cannot speak for this particular case, only the maintainers can. I can only empathise with both you and the maintainer, because i’ve been on both sides of this too :slight_smile:

There is the non-responsive maintainer process if you’d like to trigger that. It may not solve the issue, but it should elicit a response. Reaching out the maintainer via communication channels (e-mail/chat/bumping the bugzilla bug) is probably worth doing before triggering the process, though:

PS: i edited your post to remove people’s e-mails. You can tag people here using their Fedora account usernames if you wish.

–

@steppybug i disagree with your view and your “observations”. there’s no gatekeeping—have you had an issue where you “haven’t been allowed in”? Otherwise, this is not OK to say, as you are not being excellent to the community in general. The CoC requires you to be, in all community channels. Please feel free to criticise the work/the system, but not the people.

Some people who try to contribute do genuinely experience a sense of pushback and not being welcome, though (recent example post). Discussing that honestly here is something that should be OK to do.

Totally—but discussing the specific issue is different from general commentary saying that “one needs to be allowed in”. They are not the same thing.

The particular example you give can be dealt with—we have processes for that, especially if it’s behaviour that’s not in line with the CoC. It does not, however, mean that there’s systematic gatekeeping—that completely invalidates all the cases where people have been welcoming to newcomers and put in effort to help them thrive—and there many many examples of this.

I know that you and the Join SIG very sincerely do put in that effort. I do think though that it’s important to pay attention when people don’t feel that they are fully included. And that might not be because anyone has maliciously done CoC-violating things to them. There can just be a general sense that “I don’t really fit in this environment, and my voice isn’t really heard”.

Separately - is it true that as suggested in this post, “only Redhatters can be maintainers of the kernel in Fedora”?

I’m not sure I understand what you’re trying to say here. I don’t think I’ve said that we should not pay attention when people don’t feel like they fit in.

If that’s come across in my comments—that’s really not what I’m saying. I’m saying that it’s not OK to say that there’s “systematic gatekeeping” and “a facade of grass roots community” and so on. That’s the specific comment that I responded to.

So, I think we’re on the same page here.


I don’t know enough about kernel maintenance myself and Neal says that he’s been told which isn’t quite confirmation either, unfortunately. Given that the kernels need to be signed by keys and so on, which is security critical, I can see this being the case, because it will likely involve Red Hat security/legal teams and so on—but to me that sounds like only someone from Red Hat can have access to the security sensitive bits (and so make the final released build?)—community members can still help with test builds, patches, bugs and so on.


I think we’ve gone off track a bit, so I’ll wait for Rostislav to catch up before commenting any more here.

I don’t endorse those comments, but I don’t see how they violate the CoC.

They’re not directed at any individual: they’re (in my reading of them) criticisms of the relationship between Red Hat and Fedora.

@fed500 Hope you’re the same Benson Muite as the Assignee in the

bug report. I found your nickname (fed500) in LWN according to the email address that is used there:

Could you take care on the above bug reported by me in the Fedora Bugzilla or reassign it to someone that have more time for that? That issue with the glusterfs package was reported already twice and this time even with a pull request.

BTW your emails used by Fedora Bugzilla and LWN are different. Maybe this is the reason why you didn’t see both of my bug reports yet.

I’m afraid this happens quite a lot.

  • Step 1: Make an attempt or two to get in touch with the maintainer (your comment above is an ideal way to do this).
  • Step 2: If that fails, invoke the nonresponsive maintainer policy.

It’s frustrating and slow and it shouldn’t be necessary, because maintainers are responsible for reviewing pull requests. Most packages do not receive very many, so this should be a pretty small burden. But a nonresponsive maintainer does not indicate that Fedora is somehow not a community project.

The kernel package is just special. You might not be able to become a maintainer that merges changes and signs builds, but you should certainly be able to contribute.

This is what happens to me frequently:

  • Open a pull request on a package
  • Wait for several weeks with no response
  • Send email to the package maintainer asking for a review of the PR
  • Package maintainer writes back saying, “Oh, sorry, I never got any notification that your PR was opened!”

I get email when someone opens a pull request on a package I maintain, so I can only guess that these maintainers have inadvertently set their notifications to exclude PR emails.

Going on a rant is off topic.
I think you should focus on what is happening in the here and now.
Your posts have been flagged, because people already have heard you and dont want to trawl ranting.

Linus is fun to read, your not.

It’s like a record stuck in the same groove.

I would say that it is necessary to curtail AI usage to some extent. The sheer volume of AI pull requests are causing problems, especially for those who need to read emails. I’m sure the post author got ignored, partly for this very reason. It’s impossible to filter through the cruft, to find the important words being said.

One more point I should add: If someone feels like their opinion is being silenced, they may think that it might not be worth it to contribute.

I’ve been here for two years. I can unreservedly say that Fedora is a community driven project.

It is also a corporate vehicle.

These twin reasons are why I like Fedora. It is very rare for Red Hat to pull strings and get their own way. There may be times it happens, and it is arguable whether they make the right choices. I would say two out of three times they do.

Mainly though, I see community work. I see it in the forums here, I see it in packaging, I see it in our community outreach.

It is worth contributing. But there are barriers to begin. Fedora is not a hard community to work with, we have a good culture that listens and responds reasonably.
Individuals sometimes have their quirks though. And their timelines. So as you have experienced, individuals may not fit with your timescale, or might not reply at all.

We need more contributors - contributors like you - who are both human and technical.

If the post is as community-driven as you say, then why don’t you unhide my post? Surely the AI rant I made wouldn’t devalue the other things I have placed in there, would it? Even with the rant in place, it still ties in effectively with this topic as a whole, even if it branches out a bit.

In fact, I even sectioned off the rant portion for my dear readers, specifically so they wouldn’t have to trawl through it, if they’re not interested.

I want to contribute to this project, and I want others to do so as well. Silencing opinions will likely lead to some not contributing. Being unwelcoming, and having your own packagers “gatekeep” in one guy’s terms, or to be more descriptive and more precise, discouraging the to-be-packager from taking part in the packaging process for no good reason, will also do the same thing, even if what the to-be-packager is doing what an expert would consider … “dumb.” I would like the community to be more polite, and I don’t want to see a community be taken down by their own moderation team.

Is that too much to ask for?

I’ll add this quote, just for the fun of it:

(the statement he made above was completely unprompted and unnecessary, by the way)

One post taken out of context, is that the best you can do?

I make no apologises for my abrasive nature, no sugar coating.

I don’t always have a lot of time so I try to help here and there when I can. Most of my time is spent here but I’ve also written a few bug reports and some PRs. I’ve experienced what you’re describing with some packagers. I’ve had good interactions with others.

It’s not perfect and sometimes it’s incredibly frustrating but in the end it’s a great place to hang your hat.

Yes it’s not perfect, but sometimes it goes beyond all bounds of decency. A contributor spends his/her own time and energy on contributing, sometime with code change proposals, and in response gets an ignore, automatic issue closing, someone in the CC list of the Bugzilla bug report just leaves - someone who according to Bugzilla relates to this glusterfs package. What will happen this time? Will I wait a yet another year for EOL of Fedora 44 after which my bug report will be closed automatically again? What will happen with my PR? Will it be closed automatically as well? And please note that we are not talking about anything complicated or related to some experimental functionality. There is an empty directory that is created by that package spec automatically or might be created by the program itself and then it’s removed by some other procedure and this makes RPM think it’s missing. The solution should be trivial (most likely what I tried to do in my PR) and less complicated than participating in this discussion. What needs to be done to make such a trivial solution actually happen?

Would something like in the following YouTube video help, maybe? www.youtube.com/shorts/zcuSVHFq9BQ

@rosti : we do understand your frustration, and we’ve noted what the next steps here. You have started to take those steps, and you can escalate as required, including starting the non-responsive maintainer process.

I’ve also added the NEEDINFO flag to your bug, which will send regular notifications to the assignee there. (something that PRs don’t do)

In the meantime, this topic has served its purpose and is now just being used to vent frustrations and isn’t constructive any more. So, let’s all walk away for a bit and give people a chance to respond.


I want to reiterate—we are not a set of software tools that “just work” according to predefined rules. We are a community of humans, and like all humans, including you and me, we get busy, we forget things, we take on more than we can manage, we get frustrated, we get burned out, we can be impolite, we can question other people’s commitment, we can assume others don’t care. All of this and more happens, and will continue to happen.

What we also do is our best and be empathetic towards one another, and that’s what we focus on. If the system can be improved to enable us all to do better, we will change it—we’re always looking to do that. If you have ideas on how the packaging process can be improved, please open a new thread with suggestions. You will see that the community will really happily discuss it and improve—because it will help us all.

However, please do not question people’s decency or their commitment. We do not do that in the community. However frustrated we are, we must remain “excellent to each other”. That’s a necessary requirement here.

2 Likes