Reporting bugs upstream

Michael Schwendt fedora at wir-sind-cool.org
Tue May 30 11:17:20 UTC 2006


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.




More information about the fedora-devel-list mailing list