Do It For The Planet
I see folks posting to Fedora Planet with comments turned off. Sometimes I want to reply to those.
I think it’s fair to say that if you’re going to talk about Fedora, people are going to have comments. Moderated comments are ok, but let’s not disable comments on our blogs if we’re going to post here. Having to start a new blog post to reply to a blog post makes me think of this thing called email.
Similarly, Live Journal blogs with open ID enabled are good — when the Fedora Open ID thing works. However requiring someone to get a livejournal account to post is a bit strict. I don’t want a livejournal account, it’s a specific blogging service and this is why they added OpenID.
As for the slip issue, I don’t have too many dogs in the fight (dogfighting is bad unless you have airplanes), but IMHO I’ve always admired Blizzard’s “We’ll Ship It When It’s Done” stance. Trying to meet an arbitrary date and shipping something when it’s not ready is /NOT/ a good thing, and it does not help us keep friends. We should want things to be as stable as possible in core “eat my brane” areas so we can continue to attract and keep contributors (goal number one!). Seeing Fedora is free and we’re not holding up any revenue, I’d rather get a release that doesn’t blitz my MBR and give me lots of installer fun this time. You know, because I’m tired of waiting two months before it’s safe to upgrade my desktop (I of course play with my test servers much sooner).
There are basically two options of scheduling releases:
1) Feature based release. You come up with your features, you have a schedule but you release when the features are done. Blizzard does this
2) Time based release. You set a time, you release then. Features which aren’t ready are punted to the next release. Since you’re time based, it’s not that long until the next release.
The former has historically been the way that a lot of projects have worked. The latter is the direction that we have espoused for a long time and the way that many open source projects now also strive for
Jeremy Katz
November 13, 2008 at 12:22 pm
That’s entirely fair, it depends why you are slipping I guess.
I think F9 burned lots of folks, so I’m hoping F10 at least in terms of core installability takes the times it needs. If we rush stuff, I just don’t want that to impact the time it takes to get things tested.
Loosing features in a time based release is fine, test time not so much.
Michael DeHaan
November 13, 2008 at 1:02 pm
Generally, the reason we lose testing isn’t due to time, but is instead due to a lack of people testing. This has been a long-standing problem that I’m not really sure anymore how to help
Jeremy Katz
November 13, 2008 at 2:04 pm
That is hard.
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
Michael DeHaan
November 13, 2008 at 2:39 pm
I guess I’m on the other side. Fedora has decided on a six month release, so we should do a six month release. People expect to have a release at a particular time and when it slips, we look less professional.
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.
John McDonough
November 13, 2008 at 2:39 pm
I tend to prefer the time-based release; it’s certainly a core thing we push as why Fedora works so well, that regular drum beat we all dance to.
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”
Karsten Wade
November 13, 2008 at 4:30 pm
I meant Blizzard as in “Starcraft 2″
michael.dehaan
November 13, 2008 at 5:49 pm
I use Fedora primarily on my desktop, so GNOME is one of the main parts of Fedora I use and GNOME releases are time based.
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.
nicu buculei
November 14, 2008 at 12:45 am
There’s one thing to keep in mind when discussing the release model (feature based or time based):
« some people will organize events to promote the release »
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.
bochecha
November 14, 2008 at 5:57 am
Yeah, so basically it matters why we are slipping. Dates for dates sake are not interesting to me. If folks aren’t burned like they were in F9, good…
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
michael.dehaan
November 14, 2008 at 6:14 am
I’ll also abuse this post to reply to John Poelstra’s original post:
http://poelcat.wordpress.com/2008/11/13/planning-to-slip-the-schedule/
because we can’t comment on that one.
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.
Kevin Kofler
November 15, 2008 at 7:16 am
[...] a comment » One reader took issue with disabled comments at my blog. I came across the idea recently and it resonated with me. I’m trying it [...]
Trackbacks Welcome « Poelcat
December 2, 2008 at 3:40 pm