Release and update procedure for EPEL

[Thorsten Leemhuis]

On 27.02.2007 20:30, Matthias Saou wrote:
 >
> Joke aside, I'd like to see which views we have on the release and
> update procedure to apply to EPEL.
> 
> - Do we want a moving (and potentially breaking) set of packages which
>   is constantly being updated?
 >
> - De we want a fixed set of packages when a RHEL release is made and
>   focus on major bugfixes and security updates from there on?

A mix afaics. Not that rolling like Extras was, but a bit rolling.

In other words: We IMHO should have a two repos per release:

- a testing repo, where new package and bigger updates enter and get 
tested for a while. They get moved to the proper repo with each RHEL 
update (say 4.4 -> 4.5)

- a proper repo, that only gets updates for security reasons or to fix 
major bugs

We should also make sure that we have a mostly constant look and feel to 
the outside. That's why I wrote this for the wiki:

---
Is these packages a rolling release with "latest and greatest software" 
or a more "stable base and updates only when really needed"?

That needs to be discussed. But it will probably be a mix -- for 
example, a kind of rolling release, but with a careful and strict update 
policy where parts are only updated for a good reason, or not at all. 
Updating to the latest and greatest version is not possible in most 
cases, as a lot of newer packages depend on new versions of certain 
core-libs (for example, gtk, qt, and many others), which are often not 
available once the supported distribution is 12 months or older.

It also does not make sense to have a repo where some packages are 
always latest while most others and the distribution are on older versions.

The nature of the distributions in question show the user choice. These 
users prefer a stable base -- that's why they are using an 
Enterprise-class distribution that only gets updates every ~18 months. 
So why should an add-on repository for an Enterprise-class distribution 
be different?
---


CU
thl