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