I'm asking this question out of frustration. What's the point of filing bugs against Fedora at bugzilla.redhat.com when the response I get is "ask up stream they can help you"?
I filed a bug (1040518) against the Mate desktop, and was told to ask upstream for help because they can help me. I don't understand this. I installed Mate from the Fedora DVD and I therefore expect the Fedora engineers to act as buffer between me and upstream. It should be their responsibility to work with the Mate engineers, not mine.
I've done tech support for Linux for many years. Do you know how long I would have lasted if I told one of my customers "Oh, it's a kernel bug, go ask Linus I'm sure he can help you" ? I guarantee you not very long. It was my responsibility to work with whoever I needed to to fix the customer's problem, but the customer dealt with me until the problem was fixed.
OK, rant now over, you can return to your regularly scheduled programming.
Paolo
On Tue, Jan 14, 2014 at 5:24 PM, pgaltieri . pgaltieri@gmail.com wrote:
I'm asking this question out of frustration. What's the point of filing bugs against Fedora at bugzilla.redhat.com when the response I get is "ask up stream they can help you"?
At least you got a response. Half of the bugs I filed just remained unlooked at until they were closed because the release against which they were filed went out of support. Sad to say, but I mostly don't bother filing them any more. I know it's an OS without support, and I know I'm on my own when it goes wrong, but it really does feel like and area where Fedora needs to improve. If Red Hat would sell me support for RHEL at a sensible price, I'd be all over it. But they won't, so that's not an option.
Tet
I filed a bug (1040518) against the Mate desktop, and was told to ask upstream for help because they can help me. I don't understand this. I installed Mate from the Fedora DVD and I therefore expect the Fedora engineers to act as buffer between me and upstream. It should be their responsibility to work with the Mate engineers, not mine.
FOSS bug triaging is a slow, time-consuming process that relies on interested VOLUNTEERS.
Someone has triaged your bug report, and advised you of the best place to obtain support from the actual developers. Take the advice and report the bug where the developers are most likely to see your report and respond.
It is not always clear where the best place to report a particular bug is. Luckily, someone has taken the time to tell you.
The fedora bugzilla is generally best for packaging issues (e.g., missing dependencies, version X of foo broke version Y of bar). Upstream bugzillas are better for reports of program flaws.
I've done tech support for Linux for many years. Do you know how long I would have lasted if I told one of my customers
You aren't a Fedora customer. You are a Fedora user.
- Mike
Around 05:24pm on Tuesday, January 14, 2014 (UK time), pgaltieri . wrote:
ask Linus I'm sure he can help you" ? I guarantee you not very long. It was my responsibility to work with whoever I needed to to fix the customer's problem, but the customer dealt with me until the problem was fixed.
I presume your customers paid (for) you. You don't pay the Fedora engineers.
Steve
On Jan 14, 2014, at 10:24 AM, "pgaltieri ." pgaltieri@gmail.com wrote:
I'm asking this question out of frustration. What's the point of filing bugs against Fedora at bugzilla.redhat.com when the response I get is "ask up stream they can help you"?
If the bug is a packaging or dependency related bug, then use RHBZ. If it's a feature request, or broken feature that surely would affect every distro's instance of that component, then file it upstream. Often the Fedora package maintainer literally just makes sure the packaging is done correctly for Fedora.
A mechanism to push bugs upstream has been talked about on devel@ several times in the past couple years, but I guess it's non-trivial since every upstream uses a different system.
I've done tech support for Linux for many years. Do you know how long I would have lasted if I told one of my customers "Oh, it's a kernel bug, go ask Linus I'm sure he can help you" ?
Almost always kernel bugs should be filed on the kernel.org BZ. But because RH has quite a number of kernel developers, they also tend to keep on top of RHBZ kernel bugs also, but it really depends on what aspect of the kernel so unless it's a major bug I think will affect many users, or is a Fedora blocker or freeze exception type bug, I file them on kernel.org or actually more often than that I post the bug report on the upstream's mailing list.
Chris Murphy
On Tue, Jan 14, 2014 at 6:11 PM, Chris Murphy lists@colorremedies.com wrote:
If the bug is a packaging or dependency related bug, then use RHBZ. If it's a feature request, or broken feature that surely would affect every distro's instance of that component, then file it upstream. Often the Fedora package maintainer literally just makes sure the packaging is done correctly for Fedora.
True, but equally the package often comes with a bunch of Fedora-specific modifications. The end user has no way of knowing if it's a bug in the base package or in the Fedora supplied patches. Plus, my experience of reporting bugs upstream has invariably been to be told "don't use the Fedora package, try compiling our latest version from source and report back if you still have problems with that". That's a poor experience for most end users.
Tet
On Tue, Jan 14, 2014 at 09:24:00AM -0800, pgaltieri . wrote:
I'm asking this question out of frustration. What's the point of filing bugs against Fedora at bugzilla.redhat.com when the response I get is "ask up stream they can help you"?
I filed a bug (1040518) against the Mate desktop, and was told to ask upstream for help because they can help me. I don't understand this. I installed Mate from the Fedora DVD and I therefore expect the Fedora engineers to act as buffer between me and upstream. It should be their responsibility to work with the Mate engineers, not mine.
Their responsibility is in taking the upstream and packaging it for ease of installation by the Fedora users.
*IF* they can help with marshalling bugs upstream, then great! If they actually work with the upstream (as some of us do), even better!
But a lot of packagers are just that: packagers. Not developers. If you file a bug that's not against packaging process itself then there may not be much they can do for you except to say, "Sorry, can you take this to the actual developers to work on?"
Though, IMO, they should participate in that as well so that, when a fix is found, they can add it to the package.
I've done tech support for Linux for many years. Do you know how long I would have lasted if I told one of my customers "Oh, it's a kernel bug, go ask Linus I'm sure he can help you" ? I guarantee you not very long.
Fedora packagers aren't paid. It's not a job. It's a service they're providing *for free*.
It was my responsibility to work with whoever I needed to to fix the customer's problem, but the customer dealt with me until the problem was fixed.
A packager's job is to package code, not write it or fix the bugs.
On Jan 14, 2014, at 11:19 AM, Tethys tethys@gmail.com wrote:
On Tue, Jan 14, 2014 at 6:11 PM, Chris Murphy lists@colorremedies.com wrote:
If the bug is a packaging or dependency related bug, then use RHBZ. If it's a feature request, or broken feature that surely would affect every distro's instance of that component, then file it upstream. Often the Fedora package maintainer literally just makes sure the packaging is done correctly for Fedora.
True, but equally the package often comes with a bunch of Fedora-specific modifications.
I don't know how common that is because it's a lot of effort to create even slight let alone significant derivatives of upstream work. But if it is such a package then you may be better off filing a bug against it in the RHBZ.
The end user has no way of knowing if it's a bug in the base package or in the Fedora supplied patches. Plus, my experience of reporting bugs upstream has invariably been to be told "don't use the Fedora package, try compiling our latest version from source and report back if you still have problems with that". That's a poor experience for most end users.
Make sure the Fedora maintainer is being cc'd on those. Even if upstream had a way to see RHBZ bugs, I don't see how your example is avoided. If they think they have a fix in a newer base, then that's what you'd have to do or suffer with the bug until the next release. Buck passing happens to me with some regularity on OS X. The difference is "build new upstream version located here and report back" isn't even an option. So sure, tedious, do it or don't do it, your choice. But I don't see how this could work any differently than it does now, so I don't really understand what you're suggesting.
Chris Murphy
I didn't pay for the internal testing group, but I still had to fix problems they reported.
On Tue, Jan 14, 2014 at 10:02 AM, Steve Searle steve@stevesearle.comwrote:
Around 05:24pm on Tuesday, January 14, 2014 (UK time), pgaltieri . wrote:
ask Linus I'm sure he can help you" ? I guarantee you not very long. It was my responsibility to work with whoever I needed to to fix the customer's problem, but the customer dealt with me until the problem was fixed.
I presume your customers paid (for) you. You don't pay the Fedora engineers.
Steve
--
Website: www.stevesearle.com
18:00:53 up 27 days, 1:30, 1 user, load average: 0.02, 0.02, 0.00
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Even reporting upstream doesn't always help. The problem I mentioned has been sitting upstream for 3 weeks with no response. I had to create a github account just so I could post asking for an update. The general issue is there is an inconsistency with how Fedora bugs are dealt with. Some bugs are triaged and re-assigned to the appropriate component if necessary. Some are redirected upstream where they sit for weeks without being addressed, and others are not addressed at all.
If it's preferred that bugs against products are reported upstream is there a document that maps Fedora components to upstream sites?
Paolo
On Tue, Jan 14, 2014 at 11:03 AM, Chris Murphy lists@colorremedies.comwrote:
On Jan 14, 2014, at 11:19 AM, Tethys tethys@gmail.com wrote:
On Tue, Jan 14, 2014 at 6:11 PM, Chris Murphy lists@colorremedies.com
wrote:
If the bug is a packaging or dependency related bug, then use RHBZ. If
it's
a feature request, or broken feature that surely would affect every
distro's
instance of that component, then file it upstream. Often the Fedora
package
maintainer literally just makes sure the packaging is done correctly for Fedora.
True, but equally the package often comes with a bunch of Fedora-specific modifications.
I don't know how common that is because it's a lot of effort to create even slight let alone significant derivatives of upstream work. But if it is such a package then you may be better off filing a bug against it in the RHBZ.
The end user has no way of knowing if it's a bug in the base package or in the Fedora supplied patches. Plus, my experience of reporting bugs upstream has invariably been to be told "don't use the Fedora package, try compiling our latest version from source and report back if you still have problems with that". That's a poor experience for most end users.
Make sure the Fedora maintainer is being cc'd on those. Even if upstream had a way to see RHBZ bugs, I don't see how your example is avoided. If they think they have a fix in a newer base, then that's what you'd have to do or suffer with the bug until the next release. Buck passing happens to me with some regularity on OS X. The difference is "build new upstream version located here and report back" isn't even an option. So sure, tedious, do it or don't do it, your choice. But I don't see how this could work any differently than it does now, so I don't really understand what you're suggesting.
Chris Murphy
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Tue, 14 Jan 2014 11:54:58 -0800 pgaltieri . wrote:
Even reporting upstream doesn't always help. The problem I mentioned has been sitting upstream for 3 weeks with no response.
3 weeks? That's like a nanosecond in linux bug time :-). I've got bugs that are *years* old:
http://home.comcast.net/~tomhorsley/game/foolish.html
If it's preferred that bugs against products are reported upstream is there a document that maps Fedora components to upstream sites?
The closest you can get to that is to do a "rpm -q -i" which usually has an upstream website which may even exist and have links you can follow for bug reports.
Hi
On Tue, Jan 14, 2014 at 2:37 PM, pgaltieri . wrote:
I didn't pay for the internal testing group, but I still had to fix problems they reported.
Oh, come on. The internal testing group is not working for free. Are they? They are your colleagues. So the comparison is still off the mark. In some cases, I have redirected bug reporters to upstream and in some cases, I have filed it myself. It really depends on the issue and whether I already have a good working relationship with upstream, the complexity of the issue, whether I can easily reproduce the problem etc.
Even reporting upstream doesn't always help. The problem I mentioned has
been > sitting upstream for 3 weeks with no response
Yes indeed. That can happen. What did you really expect? You are not using a commercial product with any kind of support agreements. Most of the components you use in Fedora is written and maintained by volunteers who might not respond quickly to a bug report if they are busy. Even for components that has been developed primarily by commercial organizations, they aren't necessarily going to prioritize your issues. In general, I would recommend you file bug reports upstream if they aren't specific to Fedora.
Rahul
On Tue, Jan 14, 2014 at 11:54:58AM -0800, pgaltieri . wrote:
github account just so I could post asking for an update. The general issue is there is an inconsistency with how Fedora bugs are dealt with. Some bugs are triaged and re-assigned to the appropriate component if necessary. Some are redirected upstream where they sit for weeks without being addressed, and others are not addressed at all.
This is an inevitable artifact of being a community-based project with no strong ability to mandate that anyone do anything. It would be awesome if everyone could be super-responsive with all of their bugs, and knowledgeable about all of the code in the programs they package, and so on, but people have different levels of involvement, commitment, other priorities, and so on.
The best way to make this better is to pitch in where you can and set an example.
If it's preferred that bugs against products are reported upstream is there a document that maps Fedora components to upstream sites?
Well, sort of. Each package has a URL as part of its metadata, and you can see that in the Fedora Package Database. For example, here:
https://apps.fedoraproject.org/packages/calc
But there's no general indication of whether bugs should be filed in a different bugzilla -- nor, really, is there overall project agreement that that's best practice. Adding something like that on a per-package basis to the pkgdb is an interesting thought.
On Tue, Jan 14, 2014 at 9:24 AM, pgaltieri . pgaltieri@gmail.com wrote:
I'm asking this question out of frustration. What's the point of filing bugs against Fedora at bugzilla.redhat.com when the response I get is "ask up stream they can help you"?
I had a very good experience when I filed a bug in Fedora against the kernel (wouldn't boot in UEFI). I guess the kernel maintainers for Fedora are also kernel hackers, so they made the fix upstream.
I guess bug reporting is a YMMV situation.
-- Steven Rosenberg http://stevenrosenberg.net/blog http://blogs.dailynews.com/click
On Jan 14, 2014, at 12:54 PM, pgaltieri . pgaltieri@gmail.com wrote:
The general issue is there is an inconsistency with how Fedora bugs are dealt with. Some bugs are triaged and re-assigned to the appropriate component if necessary. Some are redirected upstream where they sit for weeks without being addressed, and others are not addressed at all.
This is expected when all of these things are done by volunteer.
If it's preferred that bugs against products are reported upstream is there a document that maps Fedora components to upstream sites?
I don't know. I use google search for this.
Chris Murphy
On 14 January 2014 20:17, Rahul Sundaram metherid@gmail.com wrote:
Even reporting upstream doesn't always help. The problem I mentioned
has been > sitting upstream for 3 weeks with no response
Yes indeed. That can happen. What did you really expect? You are not using a commercial product with any kind of support agreements. Most of the components you use in Fedora is written and maintained by volunteers who might not respond quickly to a bug report if they are busy. Even for components that has been developed primarily by commercial organizations, they aren't necessarily going to prioritize your issues. In general, I would recommend you file bug reports upstream if they aren't specific to Fedora.
A big part of this is that there's little communication between fedora and
other bugzillas. It's confusing and frustrating for people to report a bug against Fedora and get told they need to report it somewhere else, at the same time I realise packagers aren't keen on cutting and pasting bug reports to upstream, especially as they can't provide any information upstream might ask for. On the other hand the casual bug reporter can't be expected to be able to determine that their bug is an upstream one, so if the package maintainer or triager is able to look at a bug and say, "this is an upstream issue", then click a button to connect it upwards that would stop this being a problem.
Hi
On Tue, Jan 14, 2014 at 4:51 PM, Ian Malone wrote:
On the other hand the casual bug reporter can't be expected to be able to determine that their bug is an upstream one, so if the package maintainer or triager is able to look at a bug and say, "this is an upstream issue", then click a button to connect it upwards that would stop this being a problem.
Sure, that has been suggested many times before but it isn't easy to achieve that. For one, we don't really have any active triaging team and package maintainers have to do that triaging as well typically but the more important problem is that, bugzilla is not a universal tracking system (think launchpad, sf.net, google code tracker, github, projects using trac, redmine etc etc) and even within bugzilla many instances are very heavily customized to suit project specific workflows so trying to establish a connection to an upstream project (authentication and authorization) and finding a good way to map the information from distro speciifc bug tracker to the upstream project bug tracker and keeping track of the status etc automatically isn't an easy problem at all.
Launchpad tried to do some of this but it has failed to achieve that vision partly because it was proprietary for a long time and even now doesn't work like a regular open source project (no releases etc) and is tied to bzr version control which not many want to use.
Rahul
-
Chris Murphy -
Darryl L. Pierce -
Dr. Michael J. Chudobiak -
Ian Malone -
Matthew Miller -
Paolo Galtieri -
Rahul Sundaram -
Steve Searle -
Steven Rosenberg -
Tethys -
Tom Horsley