[EPEL] EPEL -- the way forward

Thorsten Leemhuis fedora at leemhuis.info
Wed Feb 21 18:41:10 UTC 2007

Hi all!

The idea to build Fedora (Extras) Packages for RHEL and compatible
distros like CentOS in the scope of the Fedora Project is over half a
year old now, but didn't really take of yet. This mail (and some other
work in other places like the wiki) tries to actually get the idea
running a bit more faster now in the hope that the project actually
takes of soon.

So what needs to be done:

- actually discuss the way forward with contributors and get some
feedback of potential users and contributors -- done in parts now that
you read the mail, as this is one of the purposes why it was written ;-)
- find the final name -- done already, there was (still|once again) some
discussion to use a different name for the Project. It was agreed
(agreed=no one did yell until now) on by certain EPEL SIG members that
we use a slightly variant of what was used until now -- e.g. instead of
"Extras Packages for Enterprise Linux" we'll use "(Fedora) Extra
Packages for Enterprise Linux" (note: Extra and not Extra*s*) and will
stick to EPEL as FLA (four letter acronym).
- update the wiki and put some useful and crucial informations into it
-- done mostly already. See http://fedoraproject.org/wiki/EPEL for the
current state. Some stuff will probably be added depending on what this
discussion brings up.  Note that there are quite more informations in
the wiki (including a FAQ) then this mail contains. Also note that
everything in the wiki is still under discussion and might change.
- create a fully functional SIG (see
http://fedoraproject.org/wiki/EPEL/SIG ) that takes care of EPEL, meets
on IRC regularly and make sure things are moving forward. In progress
already. Want to join? Simply add your name to the SIG list in the wiki.
- create a "EPEL Release Manager group", that together with the package
owners is actually responsible for the EL repo. They step up if
maintainers don't react in time to fix stuff like security fixes, broken
deps and similar issues that create problems for our userbase.
- allow all Extras contributors to maintain their packages in EPEL, if
they want to and are aware of the consequences; means:
-- the package needs to be supported until the End Of Life (EOL) of the
Distributions they were build for -- round about seven years. Sure,
nobody of us knows if he still be around then. But you should not build
packages for EPEL if you plan to moe oer to other stuff soon or find
packaging really annoying
-- realize that the rules in EPEL are stricter -- if you don't keep
track of you package properly someone from the "EPEL Release Manager
group" might just fix your package. If that happens multiple times the
package might get hand over to somebody else, if that the best for the
repo as a whole
- find a kind of update and release policy. See
; proposed is to have a kind of rolling release, but with a careful and
strict update policy where only stuff that really needs a update for a
good reasons gets done. Updating to the latest and greatest version is
not possible quite often  in any case, as a lot of newer packages will
depend on new versions of certain core-libs (say gtk, qt, and a lot of
others), which we in quite a lot of cases simply won't have available
when the distribution we support is 12 months or older. So why update
parts to the latest and greatest while keeping other parts on older
ersions and having a distro as a base that people are paying for because
it doesn't change
- actually start building the repo up with packages people want to
maintain and the most important packages from Fedora Extras. Maybe we
get some very rough stats from the Fedora Extras repository servers to
actually have a rough idea of which packages are popular, so we get them
build for EPEL soon and from the beginning. Ask the Fedora package
maintainers if they want to maintain them in EPEL -- if not try to find
another maintainer for EPEL quickly (the people interested in EPEL
probably might have to take care of a lot of packages in the beginning).
- get the inital batch of important and popular packages online into a
testing channel until end of march
- Make sure we have a group of people watching the usual security lists
and file bugs for open issues.
- and move them to a proper channel after some weeks if everything seems
to work.
- In parallel try to the second batch try to get all the other Fedora
packages into EPEL, but leave the "obscure" stuff out of it.
- EL-4 branches will get created from the FE-3 branch, EL-5 packages
from the FC-6 branch

I probably missed a lot of stuff. But that's why I wrote this mail, so
you can tell me and the other members of the EPEL Sig what we missed so
we can actually take care of it.

Your interested to help? Then join the SIG by adding your name to the
EPEL-SIG page in the wiki and join us in the first meeting -- that's
scheduled for Sunday, the 25th at 16:00 UTC in #fedora-meeting on the
freenode network. The mailing list for further discussions around EPEL
will be fedora-devel-list (this list); please use the tag [EPEL] in the
subject so people that are not interested in the other stuff from
fedora-devel-list can filter for it. Thanks in advance.


More information about the fedora-devel-list mailing list