bugzilla.redhat.com vs upstream bug trackers

"Jóhann B. Guðmundsson" johannbg at gmail.com
Mon Jun 17 15:55:57 UTC 2013


On 06/17/2013 03:42 PM, Jeffrey Ollie wrote:
> 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
>> instance.
> 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'm not getting paid to work on Fedora and consider myself lucky for the 
very few thanks I get for my work.

>
> 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?

Because if you cannot properly maintain the component in the 
distribution the community is better of without it.

> 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.

Then you should not be maintaining that component

>
> 2) There's a 100% chance that I don't have the time between work and
> family obligations.


We do not need unresponsive or poor maintained packages in the 
distribution and if there is really need or demand for the component you 
maintain, co-maintainers will appear or people to pick it up if you drop 
it so if you dont have the time to properly maintain your component(s) 
in the distribution then either find yourself co-maintainers or drop the 
package.

>
> 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
> a bug.

If you aren't familiar with the component you are packaging and 
maintaining why are you doing it et all?

>
> 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.

It's component's owner responsibility to be in touch and contact with 
upstream and the man in the middle role of the packager/maintainer can 
never be entirely gotten rid of.

JBG


More information about the devel mailing list