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