[haiku-development] Re: Haiku alpha 1 release (draft)

"Niels Reedijk" <niels.reedijk@xxxxxxxxx> wrote:
> I would like to share with you a list I made of all the steps I think
> need to be made from now to a release of alpha 1. Before I do this, I
> would like an informed opinion from you of where we stand. I know we
> have a 'it is done when it is done' mentality, but without actually
> defining 'done', we could wait a long time.

There is a number of open bugs that are related to R1/alpha here:
http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&milestone=R1%2Falpha

Whatever is missing there should be added in Trac as a central place to 
keep track of that information.

> So the question is, is it time to start planning?

Maybe, but not that formal IMO.
I think we should see the alpha release process as a first try - 
keeping it simple and seemless should be our first goal. Then learn 
from the mistakes we made for the beta release, and so on.

> The _packager_ is the person who creates a clean build of the source
> during the tag'n'build'n'test phase. He will provide the developers
> and testers (if any) with packages. If the packages are approved, 
> they
> are uploaded to the mirrors.

We already have automated builds. We should make sure that the specific 
revision is actually built, but anything else doesn't make much sense 
IMO. I also don't see the need to literally tag those early alpha tries 
in SVN. There is even no real need to tag the final alpha release if we 
don't intend to continue developing against that particular release; 
but since tagging is cheap I guess we could just do it and see if the 
need arises :-)
That will of course change with the more serious releases.

> The _communication agents_ are the people mentioned in a press 
> release
> that can be contacted for interviews and more information by third
> parties. There should be at least one representative from Haiku Inc.,
> and one from the core developers.

Why should that work around the usual contact method?

>  * Think of a 'blocker' policy, e.g. when are bugs blockers?
>  * Define what exactly is released: cd image? vmware image? qemu 
> image? source?

Distributions should always be released as CD image. We can think about 
additionally providing qemu/VMware images, but I don't think it's that 
important (as those are already part of the build farm).
The source is there anyway.

>  * Do something with a supported hardware list?

Would be nice.

> == Tag'n'build'n'test Phase ==
>  * Create a tag of the subversion source
>  * Create a clean build of the tagged source (package builder)
>  * Distribute this build amongst developers and testers
>  * Run tests
>  * Approve or reject the build
>  * Distribute the release to the mirrors (berlios, sf.net, torrents, 
> what else)
>  * Update trac to include the alpha1 version

This phase is a bit unclear to me (also see above).
For later releases, we should tag the first candidate, and then regard 
that as a branch and pull fixes from the trunk if needed.

Bye,
   Axel.

Other related posts: