EPEL Guidelines

Stephen John Smoogen smooge at gmail.com
Sun Apr 6 18:53:10 UTC 2008

On Sun, Apr 6, 2008 at 12:10 PM, Brad Bell <bradbell at seanet.com> wrote:
> I am a Fedora package maintainer and am considering creating an EPEL branch.
>  In the guidelines on
>    http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
>  under the heading
>    Some examples of what package updates are fine or not
>  it appears that package updates should:
>    1. be backward compatible
>    2. fix a serious bug
>  It seems that, once a package is released in EL-n, new features are not a
> reason to create a new release of the package in EL-n. An update with the
> purpose of adding new features should wait for EL-(n+1) ?

Ok I am running a fever and not feeling too hot so between allergies
and other stuff... so please make allowances:

When people started with EPEL, a lot of us had these great ideas like
making software solid and steady from quarterly release to release. A
lot of initial interest from "customers" was on this format of doing
things with the only things occurring between quarter releases was
backported patches or security fixes.

There was also a lot of people who want to get the latest "stable"
version of say cobbler, func, free-ipa since its under heavy
development and they need newer features for their environment. And so
some software gets updated monthly and some software stays 'frozen' at
some version.

I think the main thing is finding out what 'your' particular EPEL
customers want. Say what packages you are wanting to support, and what
level of maintainership you are willing to provide for EPEL and
request feedback. If the customers want a locked down version.. then
they need to provide you with the resources to make that happen.

In my dealing with EPEL software, what I have found I needed was a
solid update schedule: Black Tuesday etc, and knowing what is going to
occur in an update so I can 'freeze' a package on systems if I know I
can't go to that update... even if it means I am going to run a
security borked software piece.

Anyway.. hope the above makes some sort of sense...

Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

More information about the epel-devel-list mailing list