To update or not to update...

[Michael DeHaan]

I'm in favor of having enabling a more frequent update process for those 
who choose it. Right now, that seems to be "testing" but it's not. As 
implemented "testing"
can be a mix of very new untested packages and some that are probably in 
great shape.

When an admin adds "testing" as a repo, he gets the possibility for both.

Debian has solved this.

This is why Debian has the multi-level system:

experimental -- I just updated this package, it may eat your brane
unstable -- I think this will work, it's been in experimental for __X__ 
unit time without problems
testing -- I confidentially stand behind this package, it's been in 
unstable for __Y__ unit time without problems
stable -- really really stable

Please ignore the Debian release schedule. The process works very well 
for users, regardless of what "X" and "Y" are. As the
community size increases, I imagine "X" and "Y" can be made smaller.

Users get to pick how much they want to live on the edge. I can 
confidentally run "testing" at home knowing very little (if anything)
will ever break. I can probably even run "unstable" and be pretty safe.

So, what we are currently doing is treating EPEL's "testing" as Debian 
experimental and EPEL's "stable" as "stable".

What I would propose is the following compromise:


experimental --- all new updates go here
testing -- pushable if no defects in experimental for 2 weeks
stable -- pushed quarterly

We can basically do most of this with bohdi now.

Later, we can add the requirement that a package needs either "X" weeks 
in experimental or so many people vouching
for it to go in stable. Or whatever.

The point is -- folks run RHEL for a stable base. But it is not just a 
boxed product. It's a platform. People should be able to
choose what they do with it, and not be stuck running old&stale EPEL 
packages if they want some assurance of stability, however
minimal.

This doesn't need a QA team to implement -- it just requires one extra 
level in bohdi, and a bit of practice around it.

--Michael DeHaan