EPEL Guidelines

[Xavier Lamien]

2008/4/6 Stephen John Smoogen <smooge at gmail.com>:

> 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...
>
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20080407/aa3c949a/attachment.htm>