On Tue, 12 Aug 2014 21:05:07 +0200
Stephen John Smoogen <smooge(a)gmail.com> wrote:
At FLOCK this year, I did a short workshop on what was labeled
EPEL.Next. At that we went over a bit of what EPEL has done in the
past, what its current challenges are, and what could be its future.
Toshio Kuratomi was great in capturing what was said at the meeting
and
EPEL
* Extra packages for enterprise linux
* Lots of name recognition now
* Formed as rhel5 was being released
people needed more packages. at the time there were a ton of addon
repos. None of the m were compatible with each other necessarily.
All the other repos, dag, freshrpms, etc overrode the base os in some
places.
Decided for EPEL, overriding RHEL was something we wouldn't do.
Started with RHEL3,4 and soon after release we had 5.
RHEL was supported 5-7years and we figured we could support EPEL
packages for the same length of time.
Early controversy - repotags (shortened name that can be in the
packages.
[graph of Fedora machines measured by unique ips that hit
mirrormanager vs EPEL machines]
[graph shows steady growth in EPEL. Larger initial Fedora machines
that rose and then plateaued]
[graph shows a noticable dip every weekend. Can also see the dip in
Fedora numbers for the Incident.]
[graph is probably conservative in numbers as many enterprises
Second graph:
[Graph shows combined growth same as last graph.]
[Graph shows EPEL5 that has risen but plateaued about the time EPEL6
came out.]
[graph shows that EPEL6 has been growing and has surpassed the EPEL5
plateau.]
Where are we now:
We support 3 arches.
I think you mean 3 releases. we have 3 arches for epel5 and
epel6 and 2
for epel7
RHEL4: 1258 srpms. EOL
RHEL5: 3651 srpms
RHEL6: 5449 srpms
RHEL7: 3100 srpms and growing fastest
For CENTOS7: the epel repofile will be shipped directly with centos
for the first time.
Current Problems:
* 10+ year support for RHEL now. Hard for EPEL packagers to commit to
doing the same.
* We have requests for both newer and older conflicting packages.
- Currently policy is not to have unpleasant surprises regarding
compatibility.
- puppet2.x vs puppet3.x
* Some people need major changes to build new software
* Some people need no changes in order to keep existing software
running
* Developer burnout: People come in and after a few years, they are
burnt out because they can't upgrade the things that they want due to
the compatibility policies.
I think i would like to see us add an epel-extras repo where things can
change faster. Things like mediawiki, puppet, etc could go in extras.
Where are we going?
Pain Points:
* Inability to yum downgrade because only include one old package in
the updates tree
* Harder for EPEL than Fedora because EPEL users have more need to
rollback if an incompatibility creeps in and because EPEL users may
schedule their releases
* Not every part of package repo is suitable for inclusion in anaconda
because we may not have dep closure in the subset of the repo.
* Which RHEL point release can also make a difference because the
base RHEL sometimes upgrades incompatibly and we don't keep a
separate build for both point releases.
* Can take a long time to push packages through bodhi. Can take 7
days to push a CVE through bodhi. (global EPEL and Fedora problem)
* Not all maintainers interpret "Don't break compatibility" in the
same way.
* Many guidelines are verbal, not formal.
* Some maintainers are mainly Fedora maintainers and don't know what
people are using it for in EPEL. They respond to requests to install
or update a package out of a willingness to help but don't know what
users need.
* No guideline enforcement.
* Takes a while for new EPEL releases to be brought out once a new
RHEL release is made (because CentOS hasn't released yet).
* Traditionally, we wait because contributors may not have RHEL
entitilements so they need to have CentOS to test.
* Need entitlements for contributors to run RHEL (Easiest: Use RHEL,
SciLinux, Fermi Linux).
* Packages get added to one of the RH base repositories and then we
have to pull them from the EPEL repositories.
* Some people have extra layered products from RH and do not want us
to conflict with those. Other people do not have the layered
products and therefore want to be able to get those packages from
EPEL.
* Overlap between EPEL and CentOS Extras.
Ideas to deal with Pain
* Get RHEL licenses for contributors. There is a process but it
takes a long while because of the tax problems for giving it to
people. Current procedure is that we get requests, we give the names
to a person inside of RH and then they eventually get back to us with
licenses.
* Let's create EPIC: separate repo. 3 year lifespan instead of 10
year, rhel life cycle.
* Debian Volatile repository and also Debian Backports. These repos
contain newer versions of packages, even for Debian Stable. Good for
packages which change all the time.
* Debian also has protection mechanism that says no major or no
major.minor version updates in apt (their yum equivalent).
* Red Hat already releases different lifecycle repositories (layered
products). Why not replicate what they do.
* What about implementing EPEL as a set of projects like Fedora
Playground?
* Would change the guarantees and expectations of EPEL *quite* a
bit.
* Maybe as the way to implement EPIC rather than EPEL.
* Policy change that allows for regular major changes in EPEL.
* Can't update at any times.
* Can make incompatible changes on the next point release of
RHEL->CentOS.
* Example: When RHEL7.1 comes out we have a 30 day window to get
packages updated and new packages in that make incompatible changes.
* Archive 7.0. The toplevel 7 tree is a symlink to whatever point
release is latest.
* Formalize the governance of EPEL.
* Written policies of some sort for decision making
* Elections?
* Problems to solve:
* Don't want to just listen to the people who are loudest
* Don't want to just listen to the people who have been around the
longest
* Do we want automated testing of EPEL? yes. get it working on
whatever subset you can and we'll go on from there.
* Move to CentOS as build system? Gives us additional arches.
* Could we do an ISV program like quaid does?
something to consider is moving epel to /opt/fedora/epel or somewhere
like it, then dealing with overlap etc should be simpler, but it would
take a massive change in packaging and could really only be done in
epel8
Dennis