============
Background
============
So my time at FOSDEM was pretty much the following. Walk into the hall
where the Fedora/CentOS tables were. Get met by someone who worked on
or in EPEL. Try to have a conversation and find that it was too packed
and loud there. Walk over to the coffee area and buy the person a
coffee and listen. Finish conversation and walk back over to the
table.. [take a break every now and then to use the restroom from
drinking a 16 oz tea every 30 minutes.] This was a lot of
conversations and they did all blur together after a while. [Using a
technique I learned from Centos' Karanbir Singh at FOSDEM, I will
bring a small notebook to the next conference and write down a problem
per page per person. Then I can go back the next year and see if the
problems are still there.]
==========
Promises
==========
While they all did blur, there were many similar questions from people
that came up:
* What are the promises that EPEL makes to its users?
* Do those promises make sense? [Do we need to keep a package the same
for 5+ years?]
* Do we actually keep those promises?
* Who thinks we should be keeping these promises that various people
didn't feel were needed?
* What promises can we make that make sense and that after ~8 years we
feel we can reasonably keep?
* Who do we need to make these promises to?
As I said in the previous post, a lot of people felt that we had made
promises of fixing and updating things in EPEL over the last 3 years
but nothing really seemed to have changed. There are a lot of reasons
for that (as in people say things and after a 20 hour flight have no
idea what they said to looking at the promise and going "ok that is
fine but who is going to do the work?" to "are we even allowed to
change this?"
The last point is to me an undercurrent of a lot of conversations in
and around EPEL in the last 3 years. There is the feeling that we were
chartered nearly 10 years ago to do certain things, and we should keep
doing them because people depend on that. And it is true that some
people do depend on it, but it seems increasingly that they either
don't show up to help or are a smaller set of people than we realize.
These questions and the problems above was a long discussion between
Brian Stinson and me on Sunday evening. One of the circles that kept
coming up was "Does EPEL need to be rechartered?" EPEL is a very old
Fedora SIG, and it has gone through several incarnations in the last 8
years from when it had yearly elections for board members to when it
ran without any leadership to its recent experimentation with a new
steering committee. However during that time there have been many
rules which it has tried to keep:
1. Do not do disruptive upgrades. Try to backport security fixes or do
upgrades which do not change API/ABI issues.
2. Be prepared to support the same package for the life of an
Enterprise Linux release.
3. Never replace or conflict with packages in the base Enterprise
Linux.
4. They should never require manual updates or changes between updates.
5. Follow Fedora rules for bundling, licensing, and similar things.
There are some promises some people feel like we have made also:
1. Packages will never disappear. [They don't disappear from Fedora 12
even if it is archived.. ]
2. Packages will work from EL-X.0 to EL-X.N. [EPEL will rebuild
packages regularly to deal with any ABI items]
3. Packages are built against all of an Enterprise Linux 'base' (EG
whatever is in CentOS/Scientific Linux base).
In many cases those promises aren't kept now or when they are
attempted to be kept are impossible to do.
* Most software which uses a database back end requires schema updates
ranging from dump/reload to long running change processes.
* A lot of software rebases itself internally to the point that trying
to backport a security fix usually requires a lot of coding skill in
the package.
* The Enterprise Linux lifetime has increased from 5 years to 10 years
since EPEL started. While people were interested in supporting a
package for 3-4 years.. doing so for 10 years is too much for a
volunteer position.
* The Enterprise Linux is not the same as it was in EL-3/4/5 where
software versions were rarely 'rebased' to a newer release. Instead
software would be recoded to work in the older software as much as
possible. Currently in EL-7, the desktop and other parts of the OS
were greatly updated between 7.1 and 7.2 with the idea that this
will be the norm for all releases in order to keep the product
relevant to the majority of users.
From the above, 3 of the 5 promises are either too much to keep or
haven't been kept in a long time.
=============
What to Do?
=============
Because we haven't been able to keep many promises, but feel like we
should there seem to be a couple of options ahead:
1. Ignore and do nothing. I don't like the status-quo but I think it
needs to be listed as something that can happen.
2. Try to keep the original charter and be a lot more picky about what
is in EPEL so that we can meet those promises.
3. Figure out what we can do, and go to the appropriate Fedora body to
recharter ourselves to meet those more reasonable goals.
Now number 3 may seem to be busy work, but I have found for the
conservative minded enterprise maintainer, it is very hard to give up
doing something even if you are failing until you are told you can
stop trying. It also makes it clearer to future people working on EPEL
in 2024 what they are trying to solve and how to change when the world
of 2024 needs different solutions.
=============================
What would be in my charter
=============================
1. EPEL is run by the EPEL Steering Committee. They act as
sub-equivalents to the Fedora Extras Steering Committee, Fedora
Packaging Committee and Fedora Release Engineering.
2. Packages in EPEL will never replace or conflict with packages in
the base Enterprise Linux.
3. Packages in EPEL will follow Fedora rules for bundling, licensing,
and similar things. Exceptions to this will exist and will be
documented in appropriate place.
4. EPEL release engineering can set up systems to rebase packages in
regular intervals. [There are multiple ways of doing this that I
will try to outline in other proposals this week.]
5. The only promise of a lifetime of a package is between dot releases
of the Enterprise Linux. Maintainers should make an honest effort
to support a package for the "life" of a sub-release (6.8->6.9) but
no longer.
6. Packages in a dot release will not disappear during that
time. There is no promise after that time. [If EPSco approves of a
method that packages are regularly archived, then users can use
that as a simpler method to get old packages.]
7. EPEL only supports the current dot release. If a package in
EL-6.now works on 6.0.z that is great. If it doesn't, it is up to
the user (and not the maintainer or EPEL) to deal with it. [Again
if an archive method is setup, then those older versions would just
be in something like /pub/archives/epel/epel-6.8/ or some similar
setup]
Those are my starting points for a rechartered EPEL. Please join in
the discussion on the EPEL-devel mailing list.
--
Stephen J Smoogen.