On Mon, Oct 12, 2009 at 09:22:50AM -0700, Jesse Keating wrote: > On Mon, 2009-10-12 at 10:42 -0500, Mike McGrath wrote: > > This is not what updates testing is for. Stuff in updates testing for F11 > > is for packages that are, ultimately, destined for F-11. The experimental > > repo for F-11 would be for packages that are destined for F-12 if at all. > > Isn't that what rawhide is for? If you're on F11, but want to test > experimental stuff, well install it from rawhide. You'll get to keep > all the pieces. If we're concerned about quality, I really don't think > adding some weird mashup repos to the mix is going to help that at all. > The more repos you throw out there, the more complex an environment may > be and the complexity of the test matrix exponentially increases. Do you agree that our test coverage would improve if all the following happened? * One or more experimental branches were offered beyond Rawhide for daily work that might break critical path; * Rawhide itself -- at least the critical path -- was allowed to break less in general so it was installable more often over a cycle; and * Our releases, once they arrive as GA, restricted updates to a degree determined by FESCo to help maintain a more stable distro for our target user This might allow us to have a clearer separation from the product we push to everyone (including less experienced users), and the branch that our developers often install/run (when they can!). As a result, regular contributors and power users might be able to migrate over to using Rawhide more often and as a result benefit the stable release through more regular testing, rather than waiting for some population of testers to download an Alpha or a Beta. I'm not trying to drag the discussion away from the suggestion above. Rather, I wanted to counter-suggest that a three-pronged (stable, development, unstable) approach could work to better attain our goals. However, doing this obviously would require FESCo support and leadership over policy, some engineering work to rearrange these branches (?), and of course the general agreement that this was a worthwhile pursuit. I do agree that in this scenario, someone who wanted more latest-and-greatest should still update a package subset to Rawhide, and they would continue to have a reasonable chance of things working day to day -- which is not necessarily the case right now. Of course, it could be a concern that Rawhide wouldn't move as fast or in concert if we had everyone doing private work, but I think there's a chance for us to do something innovative in terms of how that work is managed -- in other words, something like git for Rawhide++ (where Rawhide++ is the $TOTALLY_SCARY_RAWHIDE seen in bullet one above). -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
