EPEL-faster-repo-ideas

EPEL faster repo ideas

This is a container wiki page for ideas around a separate repo from EPEL that has different policies and expectations. Note that this is all just ideas and not set in any way at this time.

What are we trying to fix?

• Outdated policies. The web pages around EPEL contain many policies and procedures which may no longer be true.

• How to make new policies. When the old EpSCO ended, things were left up to who ever was doing the work and when they had time to do it. This has lead to other bitrot in that we are not always consistent in doing things.

• How to deal with a longer lived world. When EPEL was created it was written around the idea that RHEL was a 7 year lifetime product. RHEL did semi-annual releases which updated various items but didn't have large changes. While there were community rebuilds, none of them had any partnership with Red Hat. Those things have changed and those changes require changes in EPEL.

• Other? [Please make suggestions here.]

Three repos?

We could have 3 repos for the various needs:

• epel - stays the same as it is now.

• epel-rolling - allows some incompatible upgrades via some process, no overlaps, might have different life cycle

• epel-edge - allows overlapping with base and incompatable via some process, might have different life cycle.

Technical questions

• What RHEL versions to target? For how long?

• Would this repo use fedora infrastructure alongside epel? Or CentOS infra?

• Separate branches?

• What does it build against?

• Updates?

• How do new packages enter the collection/branch? Fedora maintainer? Reviews?

Policy questions

• EpSCO governance.
  • Lifetime of initial committee (9 months?)
  • Replacement of any exiting members (replacement by formal vote, etc).
  • Size of committee (4 members? 5 members?)
  • Meeting rules (follow https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee )

• How many repos? (examples below)
  • epel,
    • epel-test
  • epel-rolling
    • epel-rolling-test ?
  • epel-edge ?
    • epel-edge-test ?

• What would faster moving mean?

• Would packages in this be able to conflict with epel packages? Base packages?

• When would incompatible changes be allowed in each branch?

• Different guidelines for specs/packages per branch?

• When would a package be expired or removed?

• What are the rules for EPEL packages currently?

• Currently packages require of 2 weeks in EPEL-testing before promotion to EPEL.
  • Can this be changed to 1 week?
  • What Constant Integration would be needed to give auto-karma?

• How to integrate packages shepherded by CentOS (or other SIGS) which may conflict with EPEL packages?

Decided

• EPSCO Governance
  • First term ends March 31st, 2015
  • New Committee takes over April 1st, 2015
  • 5 Members

The Reformed EPEL Steering Committee

Members

• Smooge

• nirik

• dgilmore

• jperrin

• bstinson