Friday, April 24, 2009

The Big Picture: Timed Release Failures

Ubuntu DVD Case RenderImage by Andrew Mason via Flickr
Jaunty should be out today (this post is scheduled), and I think  this is a good time to talk about whether timed releases are a good idea. I'll put my opinion out here at the beginning and say that, from a project management standpoint, hard release schedules are really not the way to go. Let's look at Ubuntu 9.04 Jaunty as an example.

There's a giant bug in Brasero that doesn't let a user create a video CD or DVD. Brasero claims to have this function; it appears to have this function by virtue of there being a button for it; but attempts fail because it claims that it's not possible with the available plugins. This also breaks Totem VCD/DVD writing, one of the bullet points for this release. A fix is available and in a PPA, but it's apparently (as of T minus one day) not going to be included because of the package freeze. They can't test the package and get it included in the CD on time.

That leaves a choice: push the release back a couple of days, or ship with a major bug.

Canonical used to be a little more flexible with its shipments: 6.06LTS (Dapper Drake) was delayed two months because they wanted to hammer out a few bugs. About the time that 8.04LTS came out, though, Canonical became much more serious about the day they were to release on. Countdown clocks were part of the marketing effort, and if they're showing a release but one doesn't appear, that looks really bad for the project.

As a result, 8.04LTS (Hardy Heron) shipped with a bug which prevented F-Spot from launching a second time on AMD64. The first time worked, but a late change in mono left the default photo application for the OS segfaulting on startup when run the second time. It didn't get fixed for a couple of weeks. Ubuntu 9.04 (Jaunty Jackalope) will likely have a similar (but not quite as serious) bug in the shipping version because of Brasero.

There's the other side of the argument which says that there'll always be bugs and that you just need to ship, anyway, but that's why some bugs are called  "release critical" and you need to correct them if at all possible. That "posible" thing includes delaying the release for a week.

Timed releases are fine, but don't shoot yourself in the foot. Be flexible enough to put out a good product. You can't be taken seriously by real users if you ship non-functioning product regularly. That's the big picture.

Reblog this post [with Zemanta]

9 comments:

  1. I definately have to agree with you. That bug should have been fixed before the release.

    ReplyDelete
  2. Daengbo, I agree with you on "release critical" bugs that should delay a release. I also agree with you that a deadline is not worth meeting if the released software that comes out of that date does not provide the required capabilities.

    However, I have to disagree with you on two things: one, I don't think a bug in the CD/DVD burning capabilities of Brasero is important enough to delay a release, and two, I think you are underestimating the amount of work and functionality put into an Ubuntu release. To explain the former, I can't really remember when I last burned a CD. It was probably the last time I wanted to create an installation CD for Ubuntu, which means six months ago. Therefore, I guess you can say that I would have never known that the bug even existed in the first place, had you not written about it here. Moreover, even if burning CDs is important to you, and Brasero can't meet your requirement, there are other CD burning capabilities that ship with Ubuntu, specifically K3b, which IMHO, is the best burning software I have ever seen.

    Regarding the second part, a whole operating system like Ubuntu will have many bugs and missing functionality as a result of them. The question is always the number of such missing critical capabilities. I read in the release notes of today's Kubuntu 9.04 that there are still serious problems with display drivers and wireless network management. I haven't tried it yet, and perhaps the problems are not as great as they appear to be in the release notes, but if they are big issues, then (again, IMHO) they are far more "release critical" than the CD burning capability. The reason is simple: without display you cannot use the OS and certainly you cannot burn CDs with Brasero anyway, but with Brasero not working you can still use the OS. And nowadays, living without wireless is like living in a dark cage without electricity. It might be working fine for one Osama Bin Laden, but I guess the rest of Humanity still wishes for some better life.

    Also, think of the alternative: not making deadlines. I think that everyone was mad at Microsoft for not meeting the Vista deadlines, and indeed with all the pressure they shipped a problematic OS (to say the least), and got it better only after several months and a new service pack.

    Or, a closer to home application that keeps getting delayed is the long-awaited Firefox 3.1 (aka 3.5). Like Firefox 3 before it, it is being pushed back time and again, and it seems that the project plan has no meaning whatsoever to the development teams (and I am sure this is not the case). This comes to show that there is a very fine line between shipping a product with bugs (which will always happen), and shipping a product so ridiculously late. The competition (Chrome, Safari, and to some extent IE8) shipped good and fast browsers that FF3 doesn't meet, and the only reason I still prefer FF3 is its plethora of add-ons, especially Ad Blocker. If I could use ad blockers on Chrome or Safari I would be using them all the time, and a market share lost is a market share that will be hard to get back.

    ReplyDelete
  3. MandT,
    As I've said (though this post is not one of my clearest), there are two sides to this argument. Normally, the CD burning issue wouldn't be a big deal. In fact, it's in Intrepid. The difference is that this feature has been a bullet point on their features list for the upcoming release. Marketing it has made it release critical.

    I would never underestimate the amount of work that goes into a release, but you need to dicinde out stuff that's on the install disk from stuff that isn't. Having the default app for any given function shipping inoperably is a no go.

    Let's compare the situation to Vista. Vista shipped late. They scrapped everything. It was panned by everyone. That was still better than shipping it in 2006 with a broken WinFS.

    "Release early. Release often." That's the FOSS developer's creed, but it doesn't count for distributions which want to be enterprise software. Once you make the decision to start marketing that way, you need to change a little.

    ReplyDelete
  4. I think in the scheme of things even one "marketing bullet point" is no real reason to blow the release timeline. A lot of events and campaigns WORLD WIDE get organised for these release dates, so the missing feature is weighed against the volunteer and paid person-hours that go into rescheduling the rest. In the end it's cheaper to take a very mild credibility hit (which 90% of people will be able to fix from repos in short order) versus what it means to move the release date.

    So, why have release dates be firm? It's part of what set Ubuntu apart from debian in the first place: the rate of change. Debian's stable releases come out every few years as opposed to twice a year, and most people aren't interested in waiting that long-- especially since the result is that the stable release's software is old news.

    Personally I applaud Ubuntu for being one of the only software projects of its scope that can be criticised for missing one bullet point in a major semi-annual release. That shows serious class in so many ways.

    ReplyDelete
  5. I am always disappointed by the sheer volume of gruesome bugs in every Ubuntu releases. It feels like they are walking a tightrope without a net, and doing it on a fixed timer. I understand releasing a bug free distribution is impossible, but this release is actually worse than past attempts.

    Flash doesn't install properly in Firefox, the auto-install fails, and the installer provided from adobe is for 8.04, not 9.04 or even 8.10. So, the .deb package provided by adobe fails due to libcurl3 dependencies.

    Sure I fixed it, it didn't take long, but this problem prevents me from recommending Ubuntu to anyone not comfortable with apt-get command line.

    I know they will fix it in a week or two, but first impressions are everything. Ubuntu needs to stop giving hard release dates for each version. The worst thing a programmer can do is tell the public when the program will be done.

    ReplyDelete
  6. The timed release schedules are actually THE reason I got interested in Ubuntu. As a novice Linux user a few years back, there were lots of aspects of the distro wars that didn't make very much sense to me.

    rpm or deb? I wasn't sure what that meant.
    Gnome vs. KDE? Uh... I'd need to try them.

    But I know what it means to stick to a release schedule, and one of the most worrying things about transitioning to open source for me was the number of little apps I've seen die without any contact from the dev to the user. Having a commitment to a release date is something you can communicate to new linux users that they will understand, and it is a way to signal long term commitment to the project.

    That being said, there's a way to have the best (or a little better) of both worlds. Commit 9.04 to an April '09 release, as the name implies. Shoot for week one in April, rather than April 24th. If there's a release critical bug, support a delay, but with a hard finish line at the end of April.

    ReplyDelete
  7. Thomas,
    That's kind of what I was getting at in my last sentence. Shoot for the first week of April. Give yourself some time to delay if it's necessary. The countdown timers and release parties (which TheInsiderposted about) preclude changes, even if they're in the best interest of the product.

    BTW, the pictures from the Chicago release party that I saw had all of twelve people there. I don't think that justifies pissing all the users off when they insert a CD and lose their file browser.

    ReplyDelete
  8. From my viewpoint as a user, I prefer a timed release, with bug fixes later. With a scheduled release, developers know when to stop to finalize a build. By publishing the schedule, users believe that the development are progressing.

    People had to wait for so long for Windows Vista after its Release Candidate, and... Release Candidate 2. Funny!

    Agree that timed release has a drawback, but it's still better than beta forever, like Gmail.

    Btw, Update Manager in Ubuntu has functioned frequently and very well.

    ReplyDelete
  9. hmm well I'm more 50/50 on this. I think Timed releases are a great idea for the non LTS builds. Everyone knows when the next version is out and can adjust their programs/deployments accordingly. AS for LTS builds though, I don't think it works as well. LTS should be rock solid and a small delay here and there for LTS is an acceptable price to pay for stability.

    ReplyDelete

Other I' Been to Ubuntu Stories

Related Posts with Thumbnails