Document policy for epelrescue tags
We have created a set of koji tags called "epelrescue" into which we put binary packages that we depend on, but have been removed from EPEL for some reason.
The policy for how to manage these tags has not been written. The following questions need answering:
How do we record why each package is in epelrescue?
How do we review if packages in epelrescue still need to be there? Who does the reviewing, and how often?
How do we keep the repo as small as possible?
What policy determines if a package has been in epelrescue for "too long", and how do we deal with such packages?
We don't use those tags anymore.
We don't have anything in epelrescue right now.
So this policy seems mostly done with Tim's suggested guidelines. Can we throw the text into the TWiki doc? Have we been monitoring epelrescue periodically like originally suggested?
Maybe for the lease time, we should just be more flexible and define it per-package at time of addition – with guidelines, of course. For a package that is moving from one repository to another, I could see having a fairly short lease (1–2 months). But for orphaned/dropped packages, we might want to go a LOT longer, given how hard it is for us to drop a package once we have added it. Also, let us not forget that leases can be extended or renewed!
Once a week sounds fine.
I will define "remove from epelrescue" as "untag the package, mark it as removed on the wiki page, and add the removal date".
Carl already has a script that will check if a given package is in an OS or EPEL repo.
I will iterate over the packages in epelrescue and run that script over each of them.
It is pretty much already automated.
Lease time is a complicated subject.
Some statistics that might be helpful:
RHEL release date
CentOS release date
SL release date
SLF release date
EPEL package removal date
Date majority of sites updated
2015 early August
not released as of 2015-09-23
So far we have encountered two reasons why an EPEL package was removed and needed to be included in epelrescue:
1. The package was included in a RHEL release
2. The package was "orphaned" (no maintainer) for at least six weeks
The ideal lease time for a package removed for reason 1 should be the difference between the last two columns in my table - but data is sparse.
The lease time for a package removed for reason 2 is the length of time it takes for us to decide that nobody in EPEL will step up to maintain the package, and OSG will have to maintain it.
I don't know that one, either.
So I wrote 60 days, although what I really meant was "two OSG releases". That was just a guess on my part. Maybe it should be three, maybe one.
Since the lease expiring leads to us including the package in OSG, it should definitely be tied to our release schedule.