To update or not to update...
limb at jcomserv.net
Fri Aug 17 18:49:20 UTC 2007
> 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
> This doesn't need a QA team to implement -- it just requires one extra
> level in bohdi, and a bit of practice around it.
+1. In the current world, how do we get a package out of testing? I know
I still have one with a broken dep, but once that's fixed. ..
> --Michael DeHaan
> epel-devel-list mailing list
> epel-devel-list at redhat.com
novus ordo absurdum
More information about the epel-devel-list