[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: EPEL Guidelines





2008/4/6 Stephen John Smoogen <smooge gmail com>:
On Sun, Apr 6, 2008 at 12:10 PM, Brad Bell <bradbell 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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]