bugzilla.redhat.com vs upstream bug trackers

["Jóhann B. Guðmundsson"]

On 06/17/2013 07:57 PM, Jeffrey Ollie wrote:
> OK, so this post is going to be rather long and rambling, and
> hopefully respectful, but I'm passionate about this subject (and
> Fedora).

As am I.

>   The tl;dr summary is that there shouldn't be a single
> standard for what we expect of packagers, especially in the context of
> what to expect when bugs are filed against their packages on Red Hat's
> bugzilla.

I disagree and from my pov it should be.

But I agree that RHEL customers somehow expect the same customer 
treatment RHEL provides them for bug filed agains Fedora.

I filed a ticket with the board where I asked them to come up with and 
write a wiki page which clarified that for them ( RHEL customers ) but 
that ticket has been laying in that tracker for a about 2 years now 
without any kind of movement. ( takes them maybe half an hour for them 
to come up with and wikify it )

> My view is that expectations are going to depend on the
> criticality of the package to Fedora (kernel, installer, default
> desktop stack) and the packager (are they being paid to maintain the
> package in Fedora or are they volunteering their time).

It should not matter if you get paid or not for working on Fedora 
because in the end of the day this boils down to time and by that I mean 
the time you as an employee get paid to spend on maintaining your 
package in Fedora or the free time you have to dedicate to maintain your 
package Fedora however the time required to maintain the package 
properly in the distribution still remains the same.

We should be able to provide a minimum time it takes to just package and 
provided minimum maintenance on a component along with calculate the 
average maintenance time for an existing component in the distribution, 
which in turn should provide both the employer and or the volunteer with 
the estimated time he/she needs to spend maintaining the component per 
day/week/month in the distribution

>
> Also, where some of us seem to be at odds is the definition of "proper
> maintenance" for packages.  My definition:
>
> 1) Ensure that packages meet all of the packaging guidelines.
> 2) Fix packaging related bugs in a timely manner.
> 3) Incorporate new upstream releases, in accordance with packaging
> guidelines (e.g. packages shouldn't be updated to a new major version
> in a released version of Fedora).
> 4) Incorporate patches that fix security issues or critical bugs.

The only difference is that I would add step number five acting as the 
liaison between upstream and downstream for reporters which to me is 
unavoidable for a packager/maintainer from my pov.

> In my view these expectations imply that a packager has some
> involvement with upstream.  I think that the level of involvement is
> going to depend on the packager and the package.  I don't think that a
> hard and fast rule can be developed to cover every case without
> becoming ridiculously long and complex.  Other than generally
> encouraging packagers to become involved with upstream development it
> should be left up to the conscience of the packager.

 From my point of view If you are not involved with upstream ( at least 
subscribed to their mailing list and have a account in their upstream 
tracker ) you should not be maintaining package in the distribution but 
should instead just be maintaining it in a side repo.

> In no way should packagers be expected to provide end-user support for
> packages, be an expert in every aspect of a package, or be expected to
> work with upstream to debug issues because the end user is unwilling
> to do the work themselves (in essence becoming an upstream developer
> themselves).

Agreed but at least they should know how to debug their own components 
which when I started the how to debug initiative a while back in QA 
revealed many of them did not even know how to do that.

>
> OK, so with that out of a way, I'm hopefully going to respectfully (if
> wordily) respond to Jóhann's comments.
>
> On Mon, Jun 17, 2013 at 10:55 AM, "Jóhann B. Guðmundsson"
> <johannbg at gmail.com> wrote:
>> On 06/17/2013 03:42 PM, Jeffrey Ollie wrote:
>>
>>> 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.
>>
>>> 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
> In some cases you may be right.  But in most cases I was the only
> person to step up and package a particular piece of software.  Also,
> in most cases I'm willing to step aside as the owner of a package if
> someone wants to take over the responsibility.  In every case I've
> been willing to take on co-maintainers to help out with the packaging
> duties.

So here is where I see things go wrong for many packagers they fail to 
understand or rather we fail to provide proper info on how much time it 
takes to maintain a package in the distribution.

>>> 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.
> Again, our key disagreement here is on the definition of "proper
> maintenance".  I have more than enough time to keep up with new
> versions as they are released (most of the time) or to pull a patch
> out of the upstream's version control and add it to the package. But
> even if I had the hardware I don't have the kind of time it takes to
> set up test environments to reproduce a bug, and then dig into the
> code and find the bug, develop a fix and then test it.

When you decide to maintain a component in the distribution you need to 
ensure that you have enough time to perform steps a) b) c) d) and e) not 
only steps a),b) and c).

The load or rather the time of the maintenance can however be 
distributed between co-maintainers and between existing sub communites 
in the distribution or for packagers/maintainers themselves by building 
a sub-community surrounding the component(s) in question.


>> 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.
> Playing "man in the middle" is inefficient.  Unless it's an issue with
> packaging or Fedora-specific patches the reporter should work with the
> upstream developers to identify and fix the issue.  Once a fix is
> available then it's the package maintainers responsibility to pull
> that fix into Fedora (either as a patch or a new release).  That way
> the upstream developers can work directly with the user that is having
> the problem and ultimately every distribution benefits from the bug
> fix.  The package maintainer should certainly be kept in the loop so
> that they know an update/patch is imminent.

Agreed that's inefficient but it's still a necessary and unavoidable 
part of maintainers responsibility from my point of view.
( even if we could link two bugzilla instances and fully automate the 
process that step would still be required by the downstream packager )

>
> I personally think that the level of involvement/contact that a
> package maintainer needs to have with upstream depends on the
> component.  For core components like the kernel or the Gnome stack
> expecting there to be a package (or packagers) that are intimately
> involved upstream is reasonable.

I personally dont make distinction between components or the role they 
play and if you package or otherwise maintain a component in the 
distribution then you need to at least be subscripted to their mailing 
list and have an upstream bug tracker account and promptly respond to 
reports and or when you are being directly contacted since the component 
you maintain will automatically affect QA/Releng community and 
potentially the feature process and security sub community as well.

Maintaining a package in the distribution is way much more then coming 
up a with a spec file and rolling out releases when ever upstream does...

JBG