On Mon, 2009-10-12 at 14:37 -0400, Paul W. Frields wrote: > > 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; Each added repo increases the test matrix exponentially. More repos frankly == less likelihood of getting QA coverage. Once we've frozen rawhide and are ready to polish it into a release, an updates-testing repo for the pending release makes sense. Allow people to propose freeze breaks, test them across a wide audience, and eventually push them into the pending release (or drop them on the floor). It does get hard though if you want to push say a new gecko stack, and have to rebuild 15~ packages along the way, then have to roll them back somehow. > > * Rawhide itself -- at least the critical path -- was allowed to break > less in general so it was installable more often over a cycle; and Of course this would improve QA coverage, however you need QA coverage to prevent the breakage. That's like saying "Would me giving you more money improve your lack of money situation?" > > * 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 While I'd like to see a "calming" effect on our updates, perhaps it really only matters for the critical path, changes that everybody sees, but not across every package in the distribution. One size policy, while it's easier to write down, doesn't fit all very well :/ > > 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. This is essentially the no frozen rawhide proposal that has already been acked by FESCo. Rawhide is every moving, never stopping, "unstable". We branch it away at some point (feature freeze) and start polishing it up for a release. Some development is going on, fixing bugs in features, etc.. This is "testing". It'll eventually turn into the "stable" release. I can't very well ascii draw this. > > 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). > > I think many people are struggling with the duality that is the repo we call "rawhide". For a period of time it is a repo where wild and crazy changes happen and experimentation is done. Then suddenly we throw a switch and expect all that to settle down and to start treating rawhide the repo as a stabilization point for all those wild changes. Then we throw another switch and expect rawhide to slow way down and basically halt as we test and polish it up for a release. That's a lot of different ways to treat a single repo of packages. That's why the no frozen rawhide proposal breaks that up. rawhide the path is always rawhide. Always wild and crazy, always moving forward. We create a new repo for the pending release (and give it a updates-testing like repo for proposed changes for the pending release). This allows us to slow down and stabilize without losing the benefit of wild and crazy change in rawhide. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
