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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
