Release and update procedure for EPEL
Thorsten Leemhuis
fedora at leemhuis.info
Wed Feb 28 06:43:11 UTC 2007
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
More information about the epel-devel
mailing list