Upstream bugs vs. Fedora bugs: KDE people do it wrong

Orcan Ogetbil oget.fedora at gmail.com
Tue Mar 30 03:25:50 UTC 2010


On Mon, Mar 29, 2010 at 3:30 PM, Thomas Spura wrote:
> Am Montag, den 29.03.2010, 21:05 +0200 schrieb Thomas Spura:
>> Am Montag, den 29.03.2010, 19:47 +0200 schrieb Oliver Falk:
>> > I also agree with "Fine". Pkg maintainers are responsible for their pkgs. And of course not everybody is able to fix any kind of bug...
>>
>> I also agree with Christoph. Pkg maintainers should file bugs upstream,
>> when getting a bug report and not just closing anyhow and let the
>> reporter do their job (and saying 'I watch them upstream').
>
>
> By the way:
> What is RH bugzilla for, when not using for bugs in fedora?

For packaging related bugs, or bugs related to Fedora specific
customizations on packages.

> Closing and letting the bug reporter reporting the bug again on upstream
> means RH bugzilla could directly be disabled for the packages, where
> maintainers behave like this...

Sometimes a user files a bug that I can't even reproduce. It is better
for the user to report such bugs upstream than to me. When I forward
the bug upstream, upstream asks me to test certain things and to
report back. It doesn't make sense to test something for a bug that I
can't even reproduce. Why should I play the middle man? It's
inefficient.

Nevertheless, I try to do my best to spare time to locate the bug in
many cases.  But I don't think this should be my duty. It takes time
to go through someone else's code and figure out what is wrong. I
don't always have this time.

As a user, when I encounter an error, I usually file the bug upstream
after making sure that the bug is not packaging related. Sometimes it
is not easy to figure out whether the bug originates from upstream
code or from Fedora. If I am not sure, I file a bug in Fedora's
bugzilla. If the package maintainer tells me that the bug is caused by
the X package, asks me to file the bug upstream, and closes the bug in
Fedora's bugzilla, I am totally fine with it.

Orcan


More information about the devel mailing list