On Thu, 2009-05-07 at 13:15 -0700, John Poelstra wrote: > Jesse Keating said the following on 05/06/2009 05:04 PM Pacific Time: > > On Wed, 2009-05-06 at 16:52 -0700, John Poelstra wrote: > >> The overall Fedora 12 schedule with a GA date of 2009-11-03 is 21 days > >> shorter than Fedora 11 and exactly the same length as Fedora 8 so it is > >> not unusually short. > > > > Well 21 days is a lot of days to take in, particularly when a lot of > > them seemed to come between the GA of 11 and the Alpha freeze of 12. > > I still don't understand why that matters considering the amount of > development and changes that happen up until GA no matter where we are > in the release process. Even now after final freeze lots of changes are > being ACKd on releng-list and very few if any are getting NAKd. It's a sad but true state of things. Just because we freeze doesn't mean people stop finding bugs, and if we have time to take in the bugfixes, we will, as long as they aren't threatening stability. The freeze is there to prevent the unstable things from accidentally making it in. This made even more sense when we didn't branch for the release until just before GA, now we branch a lot earlier and there is less risk of unstable things slipping in, but there are still plenty of builds that we'd rather not see hit the tree. The freeze override process exists to add a filter between developer and repo to catch the obvious and to help maintainers think a moment about what they're doing and whether it's acceptable to do in a freeze period. it would make a lot more sense if developers would treat updates to a release with the same care as they treat updates during a freeze period, but that's a fight for another day. > > >>> 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. > >> I'd be curious to see our torrent and download numbers for the F11 Alpha > >> to understand how insignificant it was. Where can we find them? > > > > Torrent numbers are at http://spins.fedoraproject.org:6969/ but > > downloads alone don't show the whole picture. By the time people got to > > the Alpha bits, the general feeling I have is that most of the bugs in > > alpha were already known, and the solution was to update to rawhide. > > Even if the bugs weren't fixed, the first suggestion was always update > > to rawhide, so rawhide is really the target we're after, alpha just > > appeared to be an easy way to get there. > > If I'm reading the information correctly there, 10,000+ people got the > Fedora 11 alpha. > > I would think that giving 10,000 people an easy starting place for a > release would be a good thing. That's assuming that those 10,000 people couldn't easily use F11 GA and then upgrade to rawhide. I don't think you can draw the conclusion that "10K people got Alpha, if we drop Alpha we'll lose 10K people". > > How will we measure--not assert or subjectively decide as we are doing > here and have done in the past--whether a change we have made helps our > releases or if time is better spent somewhere else? We just have to go on gut feeling, like just about everything else in Fedora. We have to listen to maintainer feedback, and our QA team feedback and make a judgment call. If you have better ideas, I'm all ears. The message I've consistently gotten from our developers is less freeze points, and the non-blocking freeze of alpha wasn't good enough. QA has expressed that Alpha isn't really helpful too. So now we're talking about dropping it, both to save some downtime in F12 schedule and to evaluate if we really need an Alpha snapshot. > > It seems that we continue to experiment and tweak the schedule with > different durations, freezes, etc. but we rarely collect any hard data > to evaluate whether or not past tweaks were beneficial or not. What data is there to collect? So many other things change at the same time, there is really no scientific way to experiment, measure, tweak, and experiment and measure again, showing a difference with only one variable change. > If we can't really measure our progress or lack thereof in tangible > terms, how do we really know we should continue to tweak things? Feedback from maintainers and users. > >> Although it is simple to just "not do the Alpha" it will take more > >> coordination across the other Fedora teams AND good messaging in the > >> press and wider world that no alpha is coming for Fedora 12 along with > >> the reasons why. Have we considered the cost of this trade-off to our > >> brand and community? > > > > Hard to judge the cost, however our "three tests and a release" which > > turned into "Alpha Beta Preview Release" was really designed before we > > had things such as Test Days and the easily available live images, or > > the ability to easily compose regular install images with slightly > > different package sets. The prohibitive cost to doing images on demand > > has gone down considerably, and combined with test days provides a > > better harness for gathering feedback as we go than the date based > > quickly stagnant snapshots. > > This sounds good, but how do we really know this is true? What data can > we point to? Maybe we are focusing on the wrong problem and should > instead focus on the amount of churn and changes during development. > > John Amount of churn and change is something I can't directly change. I can't even get it to change for a stable release, there is no way I can get it to change for rawhide. Given our sharp upward trend in new packages and number of packages, the change and churn is only going to get worse. So I focus on changing the things I can control, which involve schedules, freeze strategies, etc.. -- 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
