Alpha release coordination / plan

Blog post by stpere on Mon, 2009-04-06 19:03

Greetings,

I'm proposing myself as a release coordinator for the upcoming Alpha Release, and here are the highlights of the plan.

First, this plan shouldn't be applied before those conditions are met :

  • the LiveCD works quite good (with no major issues left). My understanding of that topic is that we still need the FS overlay (that allows attributes over iso9660) to support live queries. If there is anything more to add to this point, please comment. Plus, the ioscheduler should be tweaked to enhance the user experience using that media.
  • all the criticals (blockers) issues already identified are fixed. I see that a lot of them have already been taken care of; that's good! :)

So basically, my plan tries to moderate the pressure on the developper workforce while at the same time optimize the benefits from the release (attention from the community at large, etc..)

What I propose is to set a condition list, that when all met, will trigger the countdown. So here is the basic timeline I propose :

RELEASE -4 weeks : Trigger

All conditions are met according to the release comitee. Feature freeze is announced to start after this week.

RELEASE -3 weeks : Feature freeze is effective

Bugfixes only. Medium tolerance to regressions.
First release of a preview livecd at the end of the week.
QA team gets the livecd to play with. Basically, we try to boot it from everywhere :) But at this step, it shouldn't be the firsts steps of the livecd, so should be somewhat useable already.

We tag/branch/(whatever it is called under svn) the repository.. all work that might "break" things temporarely are done on the new "unstable" branch. Fixes to what will become the release goes to the "stable" branch.

We put a countdown on the website, with a hot-linkable banner so that fans can blog about it and displays the countdown on their site.

RELEASE -2 weeks :

Bugfixes only. Low tolerance to regressions.
Call to test the livecd newest release.

Backport the main fixes that have been tested in unstable.

RELEASE -1 week :

Bugfixes only!! No tolerance for regressions.

Major Fixes regarding LiveCD are still accepted.

At this point, there should only be trivial bug fixes on other components. Of course the software is still alpha, but we have to get ready for the R-Day..

Special attention is paid to documentation and website..

RELEASE -3 days :

Past this point, the alpha tree is frozen.. the final images are in production

RELEASE -2 days :

Images are uploaded, seeded, ... we get the md5sum of the images..

RELEASE -1 day :

QA team test a final time the images. There is not much to be done at that time.

RELEASE!

Press releases are sent! Website is switched in release mode! The webserver braces itself!! :)

Okay, comments welcome..

Keep in mind that it's a draft ;-) On future posts, I will start the discussion regarding the formats we will distribute in (LiveCD, UsbStick, VMWare Images, etc...)

Comments

Re: Alpha release coordination / plan

Oh, forgot to mention the IRC channel..

If you want to share on this topic, you can also come in #haiku-release on irc.freenode.net

Thanks!

Re: Alpha release coordination / plan

IMO create an 'alpha' branch and let trunk development continue. Any changes deeemed worthy for the alpha gets backported to that.

Re: Alpha release coordination / plan

Yes, that's probably wiser than what I proposed to branch the unstable.. I totally agree :)

Re: Alpha release coordination / plan

So finally the Alpha will go out!

A lot of people are thinking that the current state of Haiku is already in a much better shape than what Alpha releases are used to be.

I personnally think that, from how things are going on, the Alpha release will be Beta quality. Especially when looking at your proposed plan. It really feels like Beta stuff to me, not Alpha.

:-)

Re: Alpha release coordination / plan

This is long overdue. I thought Haiku was ready for an alpha release years ago. I have access to vast amounts of different hardware and a bootable CD image is the only way to go. Best Haiku news I've read in a long time.

Re: Alpha release coordination / plan

I've waited for a livecd since I learned about the project almost a year ago. I'm glad to hear its finally coming.

Re: Alpha release coordination / plan

I'm trying Haiku only as test image till now.
I understand (hope) that pre-release will be open to all people to search bugs in the max number of systems possible.
Is foreseen to include some app to detect the system information of the user and to generate a report of the happened bug?
I know, it looks like certain application of a "non-loved" operating system... but we should "burn" this alpha to search all bug, incompatibilities... and all information should be received to fix it.
Its necessary to give all the facilities to compile all this information.

Re: Alpha release coordination / plan

How close are we to release?

Re: Alpha release coordination / plan

Re: Alpha release coordination / plan

One thing we should do is define what hardware Haiku are supporting.

When a developer makes a driver he has xx hardware and that driver are suppose to handle xx hw and not xxy if it works with xxy then great. For example I don't know if we support all Nvidia cards? So those Nvidia cards that we do support and don't work they will be treated as bugs but those we don't support and don't work will be enhancement and dealt with after the release.

There are a lot of hw sites for Haiku but we need one that distingue between what hw a driver are suppose to support (reported by a developer of that driver) and what it can/does support (reported by the community).

Thoughts?