Document policy for epelrescue tags

Description

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.

https://twiki.grid.iu.edu/bin/view/SoftwareTeam/ResurrectingEPELPackages

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?

Freshdesk Tickets

None

Activity

Show:
Mat Selmeci
May 5, 2020, 6:43 PM

We don't use those tags anymore.

Mat Selmeci
June 29, 2017, 9:54 PM

We don't have anything in epelrescue right now.

Brian Lin
June 29, 2017, 8:24 PM

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?

Tim Cartwright
September 23, 2015, 6:27 PM

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!

Mat Selmeci
September 23, 2015, 3:51 PM
  • 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:

Point release

RHEL release date

CentOS release date

SL release date

SLF release date

EPEL package removal date

Date majority of sites updated

6.5

2013-11-21

2013-12-01

2014-01-31

2014-02-18

N/A

Damned

6.6

2014-10-14

2014-10-29

2014-11-12

2014-11-18

2015 early August

if I

6.7

2015-07-22

2015-08-07

2015-08-26

not released as of 2015-09-23

2015 mid-September

know

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.

Won't Fix

Assignee

Mat Selmeci

Reporter

Mat Selmeci

Priority

Trivial

Components