I heavily disagree with John Poelstra: I think slippage isn’t going away no matter what. Planning for a later release isn’t going to eliminate the slippage at all. It’s just going to increase the delay, because now we have the planned delay + the slippage. Case in point: when F10 slipped due to infrastructure, the decision was made to slip the whole schedule by 3 weeks “so we don’t have to slip again”. What happened? The beta freeze was missed and a 4th week of slippage happened. Had the schedule been designed to tighten up and target the original release date, we might have released only 1 or 2 weeks late.

The way you fight slippage is not by targeting a later release date, but by targeting an _earlier_ release date than the one you actually want to achieve, then slippage will just move the date closer to the one you actually want.

As long as we’re moving to be more stable than F9 at release time, keeping to the schedule is a nice thing to do, but it’s /just/ a date. The final product is more important. Things that need time deserve the time they need. I am not interested in the latest flashy Gnome in the least — what I have is fine. Fedora to me is a development platform and to lots of people, they use it power infrastructure. So, seeing what features (no capital F, I just mean features) we have in, we should do what it takes to make sure they’re right, dates are less important.

That’s pretty much all I was trying to get across.

My other thing was I wanted folks to open up comments

And this is already hard to do in our time-based schedule with all the slips, I just can’t imagine how awful it would be the other way :-/

Sure it has to be stable and well tested. But remember that some people actually need some time to plan an event, reserve the room and invite guests.

The time-based schedule is perfect. What we need is a way to reduce the slips.

The direct implication for me of the Fedora release delays is that I can’t endure the wait for the improved desktop (GNOME), so lately I move my main desktop (which is supposed to be as stable as possible and ready for work) to rawhide, did it at Beta for F9 and at Preview for F10.

So instead to doing real work I need at times to endure large amounts of updates and brokeness (currently my F10/Preview/Rawhide desktop is so broken that is really painful to use).

Also, stayng close to the GNOME release cycle was one things that helped Ubuntu get its initial userbase (at the very beginning as a distro for GNOME enthusiasts)), they also have delays, but usually manage to release each time before us.

Just catching a moment to remind you that Blizzard’s thinking evolved from that “Ship it when it’s done” Mozilla focus to a Fedora time-focus:

http://www.flickr.com/photos/christopherblizzard/376866932/

“We are Fedora
we will release
every six months

or the kitten
gets it”

John Poelstra also posted on this today, and based on his comments, I suspect we don’t have quite enough detailed data. We are moving in the direction of better tracking, and we need to keep moving in that direction. Eventually we’ll get there.

Oh, and I don’t think Michael DeHaan needs to worry about F10. IMO, the alpha of F10 was miles better than F9 GA. F9 took some risks and they didn’t work out. OK, one more lesson in the book. One might think Plymouth is the big risk with F10, but so far, it looks pretty sweet.

For me, I am working so darn far away from OS-specific bits that I don’t have a need to be tightly involved with rawhide to test it often. I wish I could, but most of my code runs on anything that can do Python 2.3.

It’s a hard problem for me to find testing on my projects too, but I have found that if a feature is exciting enough, and if you ask seven times, you can get some pretty good testing — but you always end up with the real testing happening right after the release