I never thought this would happen but I need to find a way to report a person at bugzilla. Short version, I reported and detailed a bug in fedora/redhat and the person that picked it up is sitting on it doing nothing and makes comments like below... I need to find out how to report this type of unprofessional and very unhelpful person... I have been nothing but professional about it so no idea why the comments and lack of knowledge in this person. Below is the comment and not the only one of its kind.
Reporting bugzilla person
- Thread starter APTI
- Start date
Who do you want to report it to? If it's a security issue, wait 90 days and then publish the vulnerability. Otherwise, they're not really obligated to anything, including updating their software or fix their bugs. It's not like we pay them.
I want to report the person themselves. unprofessional and argumentative. They really don't need to be part of a team with the current attitude. They are now part of the problem not just the bug as they have refused to even look into it and clearly did not read the detailed report I made showing how to reproduce it and where it is.
Report them to whom?
If it's their project, you're stuck reporting it to themselves. There's no overseer for this type of thing. There's no HR department.
If they're not the only person in the project, other project members likely see the open report and the reply. If they've not stepped in, that means they agree with them.
One of the 'drawbacks' of open source software is that we're beholden to those who maintain the project. We're not paying for support. We get what we get and we like it. The alternative is to fork the project and fix the bugs yourself.
Yeah, it kinda sucks at times.
I'd add that they can't reproduce the bug you've found. That stymies them pretty hard. They simply don't know what to fix.
We don't get to decide how a developer spends their time. Our only real recourse is to fork a project and then do the work ourselves until maybe some other people decide to help maintain the fork you've created.
If there's a project lead, you can send them an email or message them on the system. But, they're likely aware of the report and the responses given. I'm not sure that it'd help you much.
You can try amending your bug report to show them how to reproduce it, perhaps.
If it's their project, you're stuck reporting it to themselves. There's no overseer for this type of thing. There's no HR department.
If they're not the only person in the project, other project members likely see the open report and the reply. If they've not stepped in, that means they agree with them.
One of the 'drawbacks' of open source software is that we're beholden to those who maintain the project. We're not paying for support. We get what we get and we like it. The alternative is to fork the project and fix the bugs yourself.
Yeah, it kinda sucks at times.
I'd add that they can't reproduce the bug you've found. That stymies them pretty hard. They simply don't know what to fix.
We don't get to decide how a developer spends their time. Our only real recourse is to fork a project and then do the work ourselves until maybe some other people decide to help maintain the fork you've created.
If there's a project lead, you can send them an email or message them on the system. But, they're likely aware of the report and the responses given. I'm not sure that it'd help you much.
You can try amending your bug report to show them how to reproduce it, perhaps.
I gave them detailed instructions to reliably recreate the issue. The problem is the person does not know the hardware they programmed for. The detail to this is it is a raspberry pi 4b and uboot is not setting the correct voltage for the SD card. Mainly Sandisk brand, others do work. The person in his initial reply did not read what I wrote. I explained the equipment and the problem. Also that raspberry Pi OS works on the same card with no issues. Only fedora is the problem. The person that responded tried telling me that RPI4 does not power from usb C and several other things that have not been true about the Pi for at least 5 years. Then tried to blame a faulty power supply which is not the issue. the PI is powered by a large battery with buckboards to regulate voltage and amperage. The inability to reproduce is simply that the guy refuses to test on the equipment. Lazy in other words. I hope he tests the arm version of fedora on something, but all the person needs to do is spend $15 on an SD card and woomp there it is.
Sorry, not meaning to go on a tangent, but letting you know the history a bit. I love fedora so I feel that people like that should not be associated with it in this way.
No idea what project it is that you created a report for, but maybe the person doesn't have that much to spend, has other priorities or just burnt out if it's a one man project? f it's a one man project you're probably just out of a luck.
I'm not trying to start something here but just trying to share from my perspective.I have found you can come across as slightly annoying and arrogant sometimes. Not having been able read your bugzilla report since you didn't share it but I could imagine that you could have come across that way to that developer as well and is now choosing to not put any effort into your bugzilla report. Just to clear, just trying to share my perspective nothing more.
Last edited:
not to start anything either. but hello pot, I'm kettle. Actually I responded to the guy after the unprofessional treatment and told him what to do with the magic wand he mentioned. I told him to use it on his attitude. Got you on that one. I know where you mind went for a second.
The report was all factual with info on how to recreate. First time I had to report a bug to fedora and turns into a bad experience. I think the person is burned out which means maybe it is time to take a long vacation or quit. The unfortunate thing is I may have to switch a prototype out from Fedora to RPIOS. All due to something so simple.
I will offer you the olive branch if you accept.
A while ago I was trying to fix an USB SSD connected via an adapter to USB3, to use it as boot device for a rasp pi 4b. It turned out some adapters drag too much power for itself, making the pi 4b USB power limit trip in the default UAS mode piOS insists on using. The solution is to simply switch off UAS mode via a kernel quirk.
Yet, I was surprised to read on rasppi forums there actually is a boot.txt setting to increase the pi's power delivery to the ports (settings picked up by uboot). I actually tried it and it made no difference in this case, but maybe it's as a pointer with fedora too.
I'm not familiar with fedora arm, but do know the arm branch supports quite a list of devices. Sure, pi 4b might be most widely used, but a boot loader package is not custom compiled for it. Perhaps that's part of the reason why piOS works.
Anyway, what I would have surely done is to get another SD-Card..
Yet, I was surprised to read on rasppi forums there actually is a boot.txt setting to increase the pi's power delivery to the ports (settings picked up by uboot). I actually tried it and it made no difference in this case, but maybe it's as a pointer with fedora too.
I'm not familiar with fedora arm, but do know the arm branch supports quite a list of devices. Sure, pi 4b might be most widely used, but a boot loader package is not custom compiled for it. Perhaps that's part of the reason why piOS works.
Anyway, what I would have surely done is to get another SD-Card..
If there are other people working on the project, they're likely already aware of your report.
But... If there are other people working on the project, you should be able to find out how they communicate with each other to coordinate on the project. If you can find that information, you can try contacting someone else involved in the project to see if they're aware of your bug report and if they're willing to address it.
Other than that, I can't really think of anything else. It sucks and you're likely SOL, but welcome to the world of FOSS. It's not always the panacea we pretend it is and it heavily relies on altruism.
But... If there are other people working on the project, you should be able to find out how they communicate with each other to coordinate on the project. If you can find that information, you can try contacting someone else involved in the project to see if they're aware of your bug report and if they're willing to address it.
Other than that, I can't really think of anything else. It sucks and you're likely SOL, but welcome to the world of FOSS. It's not always the panacea we pretend it is and it heavily relies on altruism.
like you I tried several things to fix the issue but none worked. All I could see is I am not the only one with the issue. Uboot is the firmware fedora uses. the other distros seem to use the RPI firmware and that is the only difference. Seems uboot setting changes make no difference. Although one person suggested just ignore the error, but hard to ignore an error that prevents booting.
The problem with "just get another SD card" is it becomes a game of order a card. try it out and see "does this one work" answer? No. and go back around and around because of a software issue until you find one that works today. Strange thing is off brand card worked fine but the name brand did not. Other issue is the off brand do not last. already killed 2 in a 1 year time period with very limited use.
Although you seem to think like me, I often suggest just go get another one since they are cheap. But does not address a bug in fedora, just goes around it.
been looking into that, but not much luck. I can't imagine that this particular project is all one person. At least I sure hope not. To be honest I think the person needs to quit or take a very long vacation. suffering severe burn out. I am trying to work with them on it but if nothing happens in the next 30 days I am going to port the prototype over to RPIOS.
Well, I did not want to imply that. I've burned SD-Cards too and now only use them for static rasppi images, e.g. those not writing logfiles etc. There is plenty projects that only use overlayfs in ram - those don't care if you turn off power. Fedora is none such, default piOS neither. SSD are just as cheap these days, ultra reliable and 10x faster on the pi4b USB3.
Exactly, also perhaps you can devise a work-around. Maybe you could use a base piOS, shrink its partition to minimum, install a dual-boot fedora and use the piOS boot loader. You'd only miss rom updates, but could do this occasionally via piOS. .. just another thought.
In my experience switching to being passive reporter is the best, once it is clear it is no lacking information but more a capacity or priotization issue. The only exceptions being if you have new insight that may help finding a solution, or the bugtraq has a policy to autoclose stale issues rather quickly.
What should happen with time is other users confirming the same issue, either by finding it themselves, or a moderator merging/redirecting duplicates. Big projects like Ubuntu have extra counters for affected users, in theory to aide priorization.
What I've seen very often that after a while suddenly someone new picks up a bug report, because they were working on a related topic, and suddenly the pieces fall into place.
To illustrate it: systemd has 3107 closed and 632 open github bug reports today. Open ones go back 10 years, some get continuous work, some occasional, others none. One of the top 3 oldest (#1050) affects all unit operations in lieu with SELinux (fedora) - that is a lot of affected users. There actually was a patch for it in the year of reporting that was deemed subpar and since then occasional related commits were not enough to fix it.
It takes time. In the meantime, Linux gives more flexibility to work-around. At least there is no need to wait for Redmond fixing its compulsory updates.
never considered the dual boot with a working system to start. You know where I can find some info on how to set that up? the system has to run headless.
There's a comic out there about how the World Wide Web is built and how, somewhere in the chain, it's all predicated on some project run by a single person in their spare time. Many projects rely on code from other people. Not a lot of attention is paid to those individuals and their continutity plans.
We face the 'bus factor' as well. In fact, we face that on this site. If our lead admin is hit by a bus and in the hospital, there's nothing we can do with the infrastructure. We lack the access needed to keep the site online. If @Rob is hit by a bus, we are powerless if the domain name expires. We can't even pay to keep hosting the site.
As I mentioned above, we rely heavily on altruism. With proprietary software, there's a profit motive and often a business behind it. In our case, we've got some old nerd hanging out in his basement keeping a piece of software going for the past 30 years while moving slowly but steadily to their demise.
If the CEO of MSFT gets hit by a bus, it'll make the news, but it will not slow the development of their software.
Using us as an example, if our admin gets hit by a bus, we've lost a valuable resource for the community. With CloudFlare as the nameservers, I can't even guess the hosting provider. I can pay the money to keep the site going but there are no people I can pay it to. When the domain name expires, there's nothing I can do. There's zero chance that I'll be able to buy the domain name, regardless of how much I'm willing to spend. (It's likely a very expensive domain name. I'd pay that fee, but I'd not be authorized to pay that fee.)
If I'm hit by a bus, the missus will let folks know, and she'll keep the associated bills paid in perpetuity. Once she's gone, that'll likely be gone. But, at least there's a continuity plan. Folks will largely be on their own, but their sites will remain up and running and all that. We've gone over this multiple times and she'll deal with it when the time comes. (I also keep everything paid up several years in advance.)
So, when I die, which will happen, someone will come let folks know. Well, assuming I'm still an active member here on this site. If I've moved on, I'm not sure that anyone will take the time to let you all know that I've kicked the bucket.
CaffeineAddict
Well-Known Member
Then they shouldn't start working on any projects at all, if they're not ready to maintain it.
In the end, it is their reputation that will suffer the most, because nobody will give a sh*t about their project sooner or later.
Sure, but that doesn't stop them from starting the project. It also doesn't stop other groups of people from using their project.
Again, we rely on altruism. You can waggle your finger all you'd like. They're not beholden to you, to me, or to anyone.
Sure, there's an idyllic (and lofty) goal, but we're dealing with reality.
Note: I'm not making excuses for them. I'm just explaining the reality of it all. Frankly, I'd feel obligated to maintain any code that was widely in use and I'd feel obligated to ensure the project could continue without me (if, again, it was large enough to warrant that kind of attention).
I just updated the bug a little. also noted about 12 email addresses it was sent to. So I contacted one of those that looked like a real person. Hope that it is handled. I had a person suggest a dual boot that starts with RPIOS but not sure if fedora will just crap out with the same issue. Trying to avoid moving the project to a debian base but if it works..... This thing has to run headlessI'm with @KGIII ... likely someone else in the project will see your report and pick it up. Also, we don't know what's going on in everyone's lives, I hope the person replying to your report has a better day tomorrow.
While I wasn't referring to him specifically, I'm sure he'd be charmed by the inference.
I meant Linux, and our software and infrastructure, in general.
At one point, there was a single person keeping the NTP project going. That's what Linux, pretty much every Linux, has used for their time application. He was just some dude in, I think, Colorado. His name is/was Harlan Stenn. This got some publicity, and now there's an entire organization that takes care of the NTP project.
The bus factor is very real. It's a legitimate concern. The Linux we use, outside of the kernel, is built on a network of volunteers. Some projects are really small and have no real continuity programs. We rely on, and place our faith in, these smaller applications.
It's a risk and, again, we rely very heavily on altruism. If it wasn't for altruism, I don't think FOSS would be an option. We often don't even donate enough to cover the hours people invest in keeping the Jenga tower from collapsing.
Similar threads
Staff online
-
BrickwizardSuper Moderator
Latest posts
-
-
-
-
Another one: CIFSwitch: a non-universal Linux local root vulnerability- Latest: beanburrito