bugzilla.redhat.com vs upstream bug trackers
jeff at ocjtech.us
Mon Jun 17 15:42:15 UTC 2013
On Mon, Jun 17, 2013 at 7:49 AM, "Jóhann B. Guðmundsson"
<johannbg at gmail.com> wrote:
> It's package maintainers responsibility to act as the liason between
> upstream and Fedora thus reporters only need to report in our Bugzilla
I think that this is a fantasy that is not going to happen unless
every package maintainer's primary employment is maintaining said
packages (not necessarily employed by Red Hat).
I'm sure that I'm representative of many packagers out there - I'm not
paid to maintain packages in Fedora, in fact any open source I get to
use at work is because I've been successful at asking for forgiveness
instead of permission.
I maintain packages in Fedora because it allows me to get what I want
to do done, whether at work or at home. Since I've done the work of
making these packages, why not share them with the Fedora community?
It drives me absolutely bonkers when people open bugs on the RedHat
bugzilla and then insist that I do the work of coordinating with
upstream because they are "too busy" or they "don't want to create a
bunch of accounts in the upstream bugtracker". I mean it drives me
absolutely bonkers to the point I have trouble remaining polite. In
fact I've completely ignored a bug in RedHat's bugzilla for months
because of the reporter's attitude that their time was so much more
valuable than mine that I can't read the bug, much less post a
response without resorting to nasty four-letter words.
The work that I do in maintaining my packages is my contribution back
to the community that has given me so much already. For most bug
reports, I'm willing to take a little bit of time and see if there's a
new release I've missed or if the bug has been already identified
upstream and there's a patch that can be applied. But to expect me to
take a significant amount of time to work with upstream to find the
bug and patch it is unrealistic because:
1) There's a 99.999% chance that I don't have the resources (either
hardware or software) to reproduce the bug.
2) There's a 100% chance that I don't have the time between work and
3) Even though I'm an excellent programmer, well versed in C and
Python, and decent in Perl, Ruby, et. al. I probably don't have the
familiarity with the codebase to even know where to start looking for
4) Most software is complex enough that even configuration problems
are best handled by upstream because I'd be familiar with a small set
of configuration scenarios, but everyone's situation is unique and
understanding what exactly a configuration option does (especially in
edge cases) often requires an understanding of the code behind it.
All of this means that I'm a speedbump in the way of getting the bug
fixed, at least until there's a patch that needs to be applied to the
package, or a new release to upgrade to.
More information about the devel