Have reached a point where I feel p***ed

Mike A. Harris mharris at mharris.ca
Tue Oct 10 19:47:13 UTC 2006


Michael Schwendt wrote:
> On Thu, 05 Oct 2006 09:12:45 -0500, Rex Dieter wrote:
> 
>>> https://bugzilla.redhat.com/197033
>>>
>>> It has been enough time to downgrade the driver or request more feedback
>>> from users who are hit hard by this. But what has happened instead? The
>>> "bugzilla > /dev/null" syndrom again. Zero interest in avoiding this
>>> serious regression compared with FC5.
>>>
>>> I'm not impressed. Actually, I'm in really bad mood, and that is the
>>> case seldomly.
>> Well, for one thing, it's still marked NEEDINFO, so the assignee may not
>> still be expecting feedback.
> 
> https://bugzilla.redhat.com/203570 is still in NEW and doesn't look
> anything like encouraging either. You want another ticket filed just to
> see it closed as duplicate? Or is this some kind of educational measure,
> because Mike Harris wants Fedora X breakage reported upstream? :-}

The bare fact is, that the majority of bugs in the X server and/or
video drivers, are bugs in the X.Org codebase as shipped by the
X.Org foundation.

Regardless of what one's own personal thoughts/feelings are about
where they would like to or should file a bug report, it is an
indisputable fact that reporting a bug in any piece of software
to the place which will reach the widest possible audience of
developers who can potentially fix the issue, is going to maximize
the likelihood of the issue being fixed sooner rather than later.

That is true no matter what distribution you are using, what the
particular piece of software is, or which developer maintains that
software.

Since developer resources are finite, this fact is all the more
important.  Even more so when it comes to hardware issues rather
than general case software issues in random userland software, as
many hardware related bug reports such as for the kernel and X
server, quite often will require the person investigating the
issue to have the exact hardware on hand and be able to reproduce
it.  That of course assumes that they can justify spending the
time on a given issue when they take all of their assigned priorities
into account, which is not always the case.

I'm being quite open and honest when I say that something has to
give somewhere.  You either delay an OS release indefinitely
until your finite manpower can investigate all bugs that are
reported and fix them, or you ship an OS with many bugs not fixed.

By having people report issues directly to the source of the problem
(the upstream projects), it maximizes the eyeballs on the problem,
both on the developer side, and the people reporting the issue side,
and vastly increases the likelyhood of an issue getting fixed sooner
than later.

Now I fully understand that some people can be greatly frustrated
when a developer tells them to report the bug they've reported to
upstream.  I too sometimes feel frustrated when someone has told me
to do that, so I can fully relate.  But the logic inherent in what
I've said above holds true even for myself, and so upstream is
often the best place to report a bug period.

Now, whether one _wants_ to do that, or things they should _have_
to do that or not is totally up to the individual.  Nobody has a gun
to their head.  When a Red Hat engineer asks someone to report an
issue upstream, they're doing so because they genuinely want to
see the issue resolved, and they know that by the person reporting
it upstream the likelihood of that being accomplished increases, thus
parallelizing development/maintenance and making the software better
for all users, even those who use other operating system distributions.

People can debate the merits of this if they like, but you can't get
500 miles per gallon out of a 33 mpg vehicle.

Hope this helps others to understand why developers sometimes ask
users to report bugs upstream, and that it is done for the good of
all, even if it is sometimes slightly inconvenient for the one(s)
reporting the issue in the first place.

Take care,
TTYL




More information about the fedora-test-list mailing list