On Fri, 2015-01-09 at 11:22 +0100, Michael Schwendt wrote:
On Fri, 09 Jan 2015 09:40:17 +0200, Yanko Kaneti wrote:
> > Policy does require you to contact the maintainer
> >
http://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL
> > It is quite inappropriate to not have the courtesy to contact
> > the fedora maintainer first.
>
> I have't seen that policy, but now that I've read it it seem
> misguided. My thinking is:
> - If the Fedora maintainer cared and there was no technical reason
> the
> branches would already be there.
"Cared"? This is the fundamental problem. Care about what? About
making available a package _also_ for EPEL? Or about maintaining it
properly and
as appropriate for the long life-cycle of the mother product RHEL?
EPEL should not be treated as just another dist target to build for.
Don't take it lightly. Don't dump builds into EPEL without
considering what may become necessary for future bug-fixes, security-
fixes or even back-ports when the build requirements of an upgrade
are not met by RHEL.
It is perfectly fine, if someone with special interest in EPEL
volunteers
as the EPEL package maintainer when the Fedora package maintainer
has not
created the branches for EPEL before. Be aware of the consequences
of offering something for EPEL. It is not easy to make RHEL/EPEL
users happy.
Those, who are not affected by bugs, don't want version upgrades
which may
cause regression and new issues. Those, who are affected by bugs,
want bug-fixes (which may make version upgrades necessary!). And
there are also
those, who want always new versions as if it's a drug. Finding
existing packages saves them some work, but they don't "care" much,
because they build things themselves once the existing packages are
out-of-date, and they don't care either whether that may break the
dist.
Look, I wholeheartedly agree with all of this. This is why I only take
care of just 5 epel branches in the 35 packages that I have some say.
> - Most Fedora maintainers know well enough if there is or
isn't any
> technical reason.
Not sure about that. The type of maintenance which is appropriate
for EPEL
is underestimated. When you offer something for EPEL, you somehow
need to
predict whether you will be able to handle security fixes, backports
and/or upgrades in the future for a long time.
> - "I am too busy and I'll get to it later" - is no good excuse for
> blocking people willing to do the work.
True.
Not responding in bugzilla in time is no good excuse either.
> - "I beleive this package is not suitable for an LTS release, so
> I'll
> block it" - is just hubris.
True, too. Is there an EPEL project leadership which could review
such "decisions"? The opposite, offering something for EPEL only to
orphan it some time later, can be considered damaging, too.
> - Lets not put red tape for more people to do the work in a place
> where good sense should be more than enough to prevent conflict.
Still it's too easy to release packages in the Fedora and EPEL dists
and then abandon them without any notification.
What I dislike seeing is for potential contributors to be turned away
by our inability to trust them to do the right thing, even if we
ourselves can't find the time to do it.