In order to encourage a single-point-of-contact policy where the maintainer forwards bugs upstream, I've just entered:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178232

requesting that "UPSTREAM" be an OPEN status rather than a CLOSED one and that entering UPSTREAM status would require and upstream bug link for tracking purposes.

John

Dave Jones wrote:

On Wed, Jan 18, 2006 at 01:14:44PM -0500, John Ellson wrote:

...

Its incredibly frustrating and demoralizing to report a bug to Fedora, only to have the Fedora maintainer close the bug with the response that the user (what a dummy!) should have reported it upstream! Yes, this has happened to me.

I propose that it be a policy that Fedora maintainers are themselves responsible for forwarding the bug upsteam if necessary. At the same time the status of the Fedora bug can be left open with tracking information to the upstream bug.

In a lot of cases, users working directly with upstream instead of having someone playing middle-man is going to get things turned around a lot faster. Especially in cases where the bug relates to a specific piece of hardware, for eg.

What would be *really* awesome would be the possibility of having a facility in bugzilla to escalate a bug to upstream, so a couple of clicks, and the bug is entered in the appropriate bugzilla, with all comments being reflected back into the one the user entered the bug into. I believe there is some work going on in this area, but it's slow moving.

Dave

The bug that made me thinking about it was a bug in libwnck that I noticed after the update yesterday. I checked the redhat bugzilla en the gnome bugzilla, there weren't any reports about it. I checked the spec file and there were no extra patches. So this was abviously an upstream bug. I filed it upstream and about 2 hours later the maintainer had a patch and comitted it to cvs. Because monday new tarballs were released it will take some time before they will be in fedora I guess. So that's why I asked it here. Because it could help saving the fedora maintainer some time.

Bart

On Wed, Jan 18, 2006 at 03:41:16PM -0500, John Ellson wrote:

I more interested in the general user, or a user unfamiliar with a particular package, having a single-point-of-contact. I'm interested in not having reports discarded and lost just because they not immediately fixable by the Fedora maintainer.

For the kernel package, I did a bit of both. Sometimes I play internet traffic cop, routing the reporter to the right person/mailing list, and other times (especially when theres >1 report) I'll take it upstream myself. Neither of these are CLOSED->UPSTREAM though.

The only time I CLOSE->UPSTREAM reports is when the bug is against something we don't actively support (like XFS). Having the bug left open in the Fedora bugzilla isn't going to solve anything at all. The only chance that bug is going to get fixed is inheriting it on an upstream rebase if the upstream authors have been made aware of the problem.

...

What would be *really* awesome would be the possibility of having a facility in bugzilla to escalate a bug to upstream

That would be great, but I wonder if its overly complicated and perhaps thats why its not happening?

I think the biggest hurdle is probably that different bugzillas have different input forms, so data needs to be marshalled into a form the other end can understand.

Dave

John Ellson wrote:

...

When I find a bug in fedora and it's obviously a bug upstream I report it there. But do we have to report them in fedora bugzilla too and reference the upstream bugreport? So if an other users files a bugreport for the same bug and doesn't check upstream maintainer of the module know it's already filed upstream. Or do we have to notify the maintainer in other way? I've searched the fedora wiki for this but I can't find any information about this.

I think that Fedora users need a single point-of-contact for bug reporting.

Its tough enough to report bugs in the first place and the user can't be expected to know all the internals of every package to know if its a Fedora packaging bug or an upstream bug.

This particular topic is one in which it is extremely unlikely that everyone will ever remotely agree upon, since different people are going to look at the problem first and foremost, from the position of how the "policy", affects themselves personally, wether there a policy that is defacto, implied, explicit or otherwise.

Some people think very strongly and adamantly that "I am using Fedora Core, and so I will report bugs in Fedora Core bugzilla and that alone." They have their own personal reasons which vary, but over time I've witnessed people express their reasoning similar to what you've described above. More or less a "one stop shopping" viewpoint.

From the viewpoint of getting an actual problem solved however, this is not always the best way to report bugs. There is no single rule, and probably never will be however, so trying to apply a single piece of logic to apply to all parts of the distribution, to all developers and all packages, wont ever work. Some of the software is actually owned and maintained by Red Hat folk, directly at Red Hat, while other stuff is maintained by Red Hat folk but in an upstream project. Other stuff is maintained solely by the upstream project, with a Red Hat person or group of people also contributing occasionally to the upstream project, and often fixing things in Red Hat bugzilla too.

Its incredibly frustrating and demoralizing to report a bug to Fedora, only to have the Fedora maintainer close the bug with the response that the user (what a dummy!) should have reported it upstream!

Yes, this has happened to me.

It has happened to all of us I would suspect. Again, because quite often, the person experiencing a given problem finds Red Hat bugzilla to be a known central location, where they may already have an account set up in bugzilla, and it is simply the shortest path to ground.

On top of that, quite often when someone experiences a problem in a particular piece of software, they may be quite upset and/or frustrated about the issue. Frustrated enough to file a bug report to hopefully see the issue eventually fixed by someone, but also quite often hoping to expend the absolute minimal amount of effort to report the problem _anywhere_ as soon as possible, to make it someone elses problem real fast, and wash their hands of it.

Quite often, that approach has some serious flaws. While it is perhaps the fastest way to report an issue and wash one's hands of the problem, reporting a bug in Red Hat bugzilla, regardless of the package it is in, etc. it very definitely is not always the fastest way to get a solution to a particular problem. Sometimes it takes a bit more effort on the part of the reporter to report the issue to the best place (or number of places) possible, to increase the chances of the best people seeing the problem and having a chance to fix it sooner rather than later.

While Red Hat employees do maintain all of the packages in the OS, they are not necessarily experts in every aspect of the code in every single package they maintain. The kernel for example contains a massive amount of code, and while we have a large number of kernel engineers all of whom are kernel experts to one degree or another, there are likely several pieces of the kernel which we do not have an official "expert" in a given area. While one or more of the kernel guys may be able to theoretically dig into a given issue, they're more likely to either leave the problem to someone else who _is_ more of an expert in the given area, or to suggest to the reporter to report the issue to the upstream maintainer of that area of the kernel.

The same can be said for various other parts of the OS, but in particular some of the extra large pieces, such as the kernel, X, GNOME, KDE, OpenOffice, etc..

I propose that it be a policy that Fedora maintainers are themselves responsible for forwarding the bug upsteam if necessary.

That does sometimes happen, but it is not something a bug reporter should expect to happen. Red Hat engineering manpower is a limited resource, and our man hours are prioritized across quite a number of tasks. The amount of work that any given engineer "has" to do, plus the amount of work that they could "potentially" do (such as various random bugzilla bug reports), plus various meetings, and other things that fill the day, is generally many times more than the hours available. For example, if we were to have 100 engineers magically fall out of the sky and start fixing random bugs in bugzilla, our existing engineers would still continue to have a full workload, the new 100 people would have a full workload, and there would easily be 10 times more work than that left to do, to which there is nobody.

That means that as bugs land in Red Hat bugzilla, they simply build up endlessly, and while the number of engineers increase over time, the rate of bugs incoming is easily much greater than the increase in engineer man hours as new hires come on board.

The end result, is that some bugs, will simply sit there and rot forever, because there is not enough manpower to handle them all. So, either development stops completely while everyone drops what they are doing to go fix incoming bugs, and go report users bugs to the proper upstream location acting like a proxy, or something else has to give.

Another problem, is that even if there was a policy that Red Hat folk had to report all bugs upstream personally like you suggest, that causes some additional problems:

1) Some bugs are simply crackrock. Sometimes the developer can discern that, however sometimes that is not possible for the developer to easily determine, in particular if it is outside of their personal area of expertise.

2) Some bugs are not directly reproduceable, and may not even be a bug. If the developer reports such issues upstream themselves, and does so often, and they turn out to be red herrings, it makes the _developer_ look like an ass. The upstream developers are likely to be counting how many useless bugs Red Hat developer A reports upstream, as if it was the Red Hat person themselves having the problem.

3) It disconnects the 2 way communication link between the person having the problem (the original reporter) and the person looking into the problem (the upstream developer). The upstream developer then may ask for more information or to test something. Then there is a potential time lag between that occuring, the Red Hat developer noticing the bug email, and having time to respond to it, and to cut and paste the upstream maintainer's recommendations/questions into the Red Hat bug, and wait for the original reporter to respond again. The number of hops that occur during the problem diagnosis is increased by one - the Red Hat person who ends up wasting their valuable and limited time being a proxy for a bug that may end up turning out to not be a bug at all, or may be a configuration mistake the user made or something.

This last issue is IMHO the most important. A person reporting a bug absolutely needs to be directly involved in 2 way communication with the person or people who will be directly investigating the issue in many (but not all) cases. In particular this is true if the issue in question is highly transient and/or unreproduceable, or only occurs with rare/obscure hardware, or in complex circumstances that are difficult or unlikely to be something to set up locally to diagnose (or to justify the man-hours to the problem).

By reporting a problem directly to the bugzilla(s) and/or mailing list or list(s) that are most likely to be seen by the largest number of developers who might be able to solve a given problem, you establish a direct 2 way communication link with the people who are most likely to be able to help you, and to do so sooner rather than later, and you also make the problem solving equation become a scalable quantity.

On the other hand, by reporting a bug in Red Hat bugzilla and washing your hands of the issue, while that makes life easiest for you to report it and forget about it, depending on the nature of the problem, the Red Hat engineer determined severity and impact of the issue, the priority of your issue in the eyes of the engineer compared to all other issues on that person (or group)'s plate, may get your issue investigated right away, perhaps next week, or if it is deemed lower priority than a whackload of other stuff on everyone's plate, your issue may simply sit in bugzilla and rot until a new OS release comes out. No, this doesn't sound wonderful, but it is a blunt reality that there aren't enough people to investigate every single little problem someone tosses into our bugzilla, so some get investigated, and others sit there. Report the problem to the place that is most likely to get a quicker response (quite often the upstream project), and your problem is more likely to get solved sooner than later, even if it takes more effort on your part.

My take is that there will always be some people out there who take a hard line view that they should never have to report something to anywhere but Red Hat. Nobody, including myself is likely to convince all people out there otherwise, and so I wont try to. I merely state the facts, that if you solely rely on Red Hat bugzilla to report every single problem you have, then you also have to accept the fact that your problem is going to be fed through the available manpower resources pop-straw, and individual and group prioritization inherent in our jobs, which may get your issue investigated, or may leave it sitting in bugzilla forever, or perhaps you'll be asked to report the issue to a more appropriate place.

So, people will be people, and report whatever they want, to wherever they want. That is the nature of things. And Red Hat folks will do our jobs as we're paid to do, and prioritize things as best we can realizing we can only solve a fraction issues compared to all that end up getting reported. Since we want to see more issues fixed for people, we will try to help things scale by telling people to report issues upstream, and leaving it up to them in some cases, and in other cases doing it ourselves. There are no hard rules to the bug reporting game, and since each bug is different, each software package is different, each project different, and each maintainer and group is different, everyone will experience a variety of different results. ;o)

My words of advice to those that truly care about their bugs, is to report it to the place that gives the highest likelyhood of hitting the most people who are likely to be able to solve your problem. Beyond that however, I certainly can't twist your arm, nor would I want to. Do whatever you prefer, and we'll do what we need to do at the end of the day as well.

Hans de Goede wrote:

Mike A. Harris wrote:

...

<very long reply by Mike snipped> >

Just think how many bugs you could have looked at and maybe fixed while typing this reply :)

Just think how many bugs I wont have to waste time looking at if even a small handful of testers and end users read what I said and consider my viewpoint about it to be sensible enough to cause them to start reporting their issues directly upstream more often. The amount of time that saves me from having to wade through hundreds of bugs, will return to me a lot more time to actually spend on some of the ones that are currently in bugzilla.

On Fri, 20 Jan 2006 05:37:40 -0500, Mike A. Harris wrote:

...

I propose that it be a policy that Fedora maintainers are themselves responsible for forwarding the bug upsteam if necessary.

Good proposal.

That does sometimes happen, but it is not something a bug reporter should expect to happen. Red Hat engineering manpower is a limited resource, and our man hours are prioritized across quite a number of tasks. The amount of work that any given engineer "has" to do, plus the amount of work that they could "potentially" do (such as various random bugzilla bug reports), plus various meetings, and other things that fill the day, is generally many times more than the hours available.

Have you ever before thought about this from the user's perspective?

How many bug tracking systems does a single user need to create an account for? How many other forms of bug reporting systems does a single user need to subscribe to [and need to stay subscribed to for a long time] before communication with upstream developers becomes possible? How much knowledge of a given OS environment and an application's dependencies is needed to decide whether a problem is OS-specific or not?

What the user thinks when he encounters a problem is that "Red Hat's [or Fedora's] product is broken". And that's right. It ought to be in your best interest to track each and every defect and make sure as many defects as possible are fixed either in conjunction with upstream developers or by yourself.

As a user, being confronted with "just another feature-overloaded bug tracker" which contains many new and poorly named and insufficiently described "products" and "components" and hundreds of open bug reports, it is a very frustrating experience to spend time on _trying_ to help by reporting something upstream only to learn that the report is ignored or closed as duplicate or closed as NOTOURBUG or not been looked at for many months.

On Tue, 2006-05-30 at 08:47 -0400, Horst von Brand wrote:

Michael Schwendt fedora@wir-sind-cool.org wrote:

...

As a user, being confronted with "just another feature-overloaded bug tracker" which contains many new and poorly named and insufficiently described "products" and "components" and hundreds of open bug reports, it is a very frustrating experience to spend time on _trying_ to help by reporting something upstream only to learn that the report is ignored or closed as duplicate or closed as NOTOURBUG or not been looked at for many months.

Why not adopt some packages, and help out by keeping an eye on bugzilla for them, trying to reproduce bugs, and kick them upstream as needed? That way you don't have to learn about many upstream bug trackers, just a few. --

If anyone is interested in that, http://fedoraproject.org/wiki/BugZappers

Rahul

On Tue, 2006-05-30 at 15:01 +0200, nodata wrote:

...

On Tue, 2006-05-30 at 08:47 -0400, Horst von Brand wrote:

...

Michael Schwendt fedora@wir-sind-cool.org wrote:

...

...

As a user, being confronted with "just another feature-overloaded bug tracker" which contains many new and poorly named and insufficiently described "products" and "components" and hundreds of open bug

reports, it

...

is a very frustrating experience to spend time on _trying_ to help by reporting something upstream only to learn that the report is ignored

or

...

closed as duplicate or closed as NOTOURBUG or not been looked at for many months.

Why not adopt some packages, and help out by keeping an eye on bugzilla for them, trying to reproduce bugs, and kick them upstream as needed? That way you don't have to learn about many upstream bug trackers, just a few. --

If anyone is interested in that, http://fedoraproject.org/wiki/BugZappers

Rahul

Isn't this a workaround for bugzilla lacking an easy way to move bugs upstream? Wasn't the XML RPC interface meant to solve this?

Upstream projects use different versions of bugzilla and various other bug tracking systems. There isnt a universal method of doing it automatically. In some cases XML RPC does help.

Rahul

On Tue, May 30, 2006 at 03:07:17PM +0200, nodata wrote:

So I guess this is being worked on?

FYI, this was discussed in today's IRC meeting for Bugzilla devs.

http://bugzilla.glob.com.au/irc/?c=bugzilla-meeting&a=date&s=5+Jun+2...

Emmanuel

Pete Zaitcev wrote:

...

When I find a bug in fedora and it's obviously a bug upstream I report it there. But do we have to report them in fedora bugzilla too and reference the upstream bugreport? So if an other users files a bugreport for the same bug and doesn't check upstream maintainer of the module know it's already filed upstream. Or do we have to notify the maintainer in other way?

It depends on the package, but usually the Fedora maintainer taps into an announcement list for the upstream project, so he sees those.

This does not preclude users from filing into our bugzilla. I used to do this in preference to upstream. The logics behind it was that we may be shipping a derivative, while the upstream only wants to hear about bugs reproduced on the pristine upstream. Maintainer filters and reports upstream such bugs. It is the way kernel operated, because it used to be noticeably divergent from its upstream. But for most packages it's not needed, so your way is better.

BTW, I like dups, because users often confuse same symptoms with same bug. I have dozens of people reporting "my kernel said ``ep0 timeout''" for dozens of wildly different problems, all ending in the same bug which can never be resolved. I would much prefer users filing dups than polluting unrelated bugs. But in X, the situation is the opposite: 100 dups for the same thing, and Mike Harris wants his users to search for dups and avoid filing new ones (if I understand him right).

Not exactly... For X, we experience both problems. We get many people reporting the exact same issue without them even bothering to check for duplicates, in which there is no question at all that it is the exact same issue. That is kindof irritating, in particular when there is a very large amount of work to do and deadlines pressing on us, and there are a million new bug reports to wade through, and find the master dupe for them, and close them all, etc.

However, we also get cases where someone reports "My Radeon crashes with new X update", which then some other person tacks on "yeah, my nvidia blah blah does that too, both with the original FCx release and with the update", then someone else "I have the same problem too! But with Trident!", then another nvidia user with a totally unrelated problem to any of the other people. They all have their X server crashing for various different unrelated reasons, but since the symptom sounds similar enough, they all pile on to one big report. Then when you ask the original reporter for their log/config or to try something specific to their problem - every one of them does it and reports back the results. Even if your advice was obviously specific to the radeon for example, an nvidia user will try it on their card, and perhaps complain that the option gave an error or something.

Very irritating. However, all of the userbase does not have the same technical skill level, or troubleshooting abilities, etc. so it is more or less a fact of life that we have to deal with. It's not as bad as it was at one point though, or at least it seems a bit better now. ;o)

The biggest problem we face as far as X is concerned though, is that at least the X server is like a part of the kernel, in the sense that it has a bunch of hardware drivers with all the idiosyncracies of hardware at play. A large number of driver related problems get reported in bugzilla, and our team does try to handle as many issues as we can, given the resource constraints we are under, however the number of bugs in the X server, drivers, xkb, etc. etc. vastly outstaggers the number of manhours our entire team probably 100:1 or worse. Many people insist on filing bugs in our bugzilla rather than X.Org bugzilla for issues that are not really distribution specific to Fedora Core however, and so they pile up over time due to a combination of lack of hardware, lack of manpower, and in many cases lack of reproduceability.

While some people are now reporting things directly to X.Org, the majority of driver issues still hammer into our bugzilla. The sad thing is that many of the issues could likely be fixed in a day, a week, or a month if reported to X.Org, simply because there are so much more many developers and hardware available upstream, etc.

Ah well, such is the toil of bugzilla. ;)

fre, 20 01 2006 kl. 12:09 +0100, skrev Ralf Corsepius:

Put yourself into the role of a user, then you'd notice that

• duplicate search in RH's bugzilla often is close to being impossible

[I usually search for duplicates, before reporting, nevertheless I still end up filing duplicates, because the duplicate search had failed.]

• Users are filing "bugs by symptoms", because the often don't know the

cause. Therefore you will always find duplicates, because users often have no possibility to identify bugs as duplicates.

You need applauds, it's sometimes extremely hard to figure out the root cause of a problem a few weeks ago I was chasing 3 seperate crashes in gdm, evolution and epiphany on Ubuntu Dapper - only after filing bugs (with backtraces) for each application and doing hours of research did I realise the cause of the behaviour was pango. I can't read a backtrace to save my life but I can obtain them.

Luckily Fedora unlike many distributions care enough about their testers to provide easily installable debug symbols, without that feature I doubt I would be on the development release. But there are still things that could be done to ease bugtracking, lately I've been looking into the Collaborative Bugs Tracking project and othe similar projects which would enable all the magic to take place behind the scenes. Implementing that might work to our advantage.

Regardless of this, if we want the ability to tag a bug as being upstream, unrelated to the distro - Ubuntu' Malone tracker actually enables this and a heap of other nice stuff to integrate the various bugzillas for all the many pieces of software that make up Fedora. If only dear Mark Shuttleworth would release the code for Launchpad then we could start moving to that - having worked with Malone and Rosetta quite a bit I can only say they are good products and hopefully we'll all be able to enjoy them soon enough.

-David Nielsen