Unresponsive maintainer : kanarip

[Michael Schwendt]

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.

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