From Fedora Project Wiki

Line 2: Line 2:


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.
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? ==
== Three repos? ==

Revision as of 14:17, 2 September 2014

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

  • 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?

The Reformed EPEL Steering Committee

Members

  • Smooge
  • nirik
  • dgilmore
  • jperrin