Unresponsive maintainer : kanarip

[Yanko Kaneti]

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.