EPEL Guidelines

[Brad Bell]

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

[Rahul Sundaram]

Brad Bell 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) ? 
The simple rule: Don't release an update unless absolutely necessary. 
This is to avoid regressions.

Rahul

[Stephen John Smoogen]

On Sun, Apr 6, 2008 at 12:10 PM, Brad Bell <bradbell(a)seanet.com&gt; 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"

[Xavier Lamien]

2008/4/6 Stephen John Smoogen <smooge(a)gmail.com&gt;:

>  On Sun, Apr 6, 2008 at 12:10 PM, Brad Bell
> <bradbell(a)seanet.com&gt; 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...
>
>  
It also mean that it's _you_ packager to know [how|when|what] update an
release from upstream for a specific branch by taking in order the severity
of the new release.
that imply to know the role of each branch as well.


-- 
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB