On Wed, 2009-05-06 at 05:45 -0700, John Poelstra wrote: > Reading the IRC log am I correct in understanding that a more detailed > summary is: > "Remove all alpha release tasks from the schedule. > There will be no alpha release because it does not > provide enough value for the effort required to create > it. There is little public testing value from it > either." > ? Not fully known yet. Basically because 12 is such a short cycle, I was looking for ways to maximize uninterrupted development time. The best way I could do that was to drop the Alpha cycle. While already a non-blocking freeze, it still drew too much attention away from ongoing development in order to deliver something that was weeks old and already irrelevant. The alpha has had dubious quality to the development cycle, at least from the developer and tester POV. About the only thing of quality it provided was a "known good starting point" for which to install and then update to rawhide, and even that hasn't been true for large swaths of folks in recent releases. > > 1) What dates are we proposing for releasing "development snapshots" > before the beta? We should put these on the schedule now. I honestly hadn't planned on doing regular snapshots during this period. Instead I was hoping for some test-days to drive the need for live images and/or full media images for a particular test target. For people looking for a good "jumping off" point, they can install the GA of F11 and yum update to rawhide. > > 2) The alpha release has always been a good first opportunity to start > marketing our next release, sending out press releases, etc. Basically, > drawing attention to the fact with the general public that a new > release is in the works. Without an Alpha the first general press > releases would be a month later. Is this okay? I think so. Alpha rarely had any features in a state that we'd want to start showing people anyway. Traditionally Alpha releases are internal only and useful for whitebox testing. We can get Alpha level testing out of the rawhide snapshots. > > The Alpha also naturally gets the release notes process and other parts > of Fedora going (not development focused tasks) early which is a good > thing. We'd be losing that too. Yep, that is indeed something to consider. > 3) If we do away with Alpha as we know it, leaving two test releases, > can we simply call them "Alpha" and "Beta"? I've always thought "Preview > Release" was a funny name for a test release and I think the terms > "Alpha" and "Beta" are more familiar to the general public. Honestly, I don't think Alpha fits there. Our existing Beta release is when we want to start blackbox public testing of our features, and that isn't changing. That's still the point where we want wide public usage and testing of our features and release, to gather bugs and feedback for the second half of development, the bug fixing. I tend to agree that "Preview" is a bit of an odd name, however I refuse to call it "Release Candidate" like some other projects do, as it really isn't such a thing. There is 0 chance that our Preview release could become the final release. So we have to call it something. Maybe Gamma or Delta or Omega or Zenith would fit here, although not as widely used. It's the last snapshot mirrored before release candidates are actually created and a release candidate is picked as is to "release to manufacturing" (which in our case means stage for the mirrors). Frankly we can play with the names a bit as we go or after we pick the dates, but the rough dates are what we're trying to pass through now. -- 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-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
