bugzilla.redhat.com vs upstream bug trackers

[David Tardon]

On Mon, Jun 17, 2013 at 09:49:37PM +0000, "Jóhann B. Guðmundsson" wrote:
> On 06/17/2013 07:57 PM, Jeffrey Ollie wrote:
> >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.

That is your opinion. Others can have their own opinions about the
matter.

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

And how is this relevant here?

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

Because there is no way to quantify that. Because the world is not black
and white and it differs from package to package.

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

What are these steps?

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

I see two interpretations of the above paragraph:
1. You imply that the solution is to put every existing maintainer into
   several groups/sub-communities.
2. You think that there are hordes of people eager to become
   co-maintaineres, if only we had given them the chance.

Both are wrong.

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

It is by no means unavoidable. In fact, it is very easy to avoid.

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

Says who? The people around here are _volunteers_, not slaves. One does
not create a community by forcing rules on others.

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

This is purely your interpretation.

D.