On Thu, 21 Sep 2006 11:35:41 -0600, Stephen John Smoogen wrote: > It is probably too complicated, but I have not seen a proposal that > would be useful for an enterprise environment that is not complicated > :/. Yes. Not necessarily "complicated", but much more complex than what we (= Fedora Extras) have used so far. Proposals are not helpful when currently we demonstrate that we run into quite severe problems while preparing FE6 despite the fact that we don't have any "complicated" requirements (e.g. at the QA-level). A simple "rebuild everything for a new target platform" won't suffice. > C) That if a package is broken, how is it broken, why is it broken, > and who/when is fixing it. Same applies to _all_ updates, so preferably there are few cases of "engaging into a release-race with upstream projects just for fun". > Basically if I am subscribing to a repository for my systems.. I want > to know that it is NOT going to cause my mail cluster to stop > recieving emails at 2 am because someone pushed out the brand-new > release from squirrel-nuts.org of a perl module that had a side effect > but no one bothered to test it before it hit extras. Along the same line of thinking, you also don't want to be confronted with "unexpectedly orphaned packages" either. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
