[haiku-development] Haiku alpha 1 release (draft)
- From: "Niels Reedijk" <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 3 Feb 2008 13:28:23 +0100
Hello guys,
I hereby would like to announce the immediate release of Haiku R1
alpha 1. This is the first developer preview of the upcoming Haiku
platform. Even though this is still work in progress, we are proud to
release this as a demonstration of our work the past five years.
... Or so I hope to see soon :-)
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.
Personally, I've been able to use Haiku with mixed success.
Nevertheless, I think it is complete and stable enough to create a
developer preview (AKA as alpha 1). It might give us some momentum.
At the end of the message, I attached my list of tasks. It is in Trac
wiki formatting (because I figured it would end up there), to
illustrate what I'm getting at.
So the question is, is it time to start planning?
Niels
= Haiku R1 Alpha 1 Release Tasks =
This is a list of all the tasks that need to be performed for a alpha
1 release. This list is being maintained by the release coordinator -
who is yet to be appointed. Please use the development mailing list
for additions, to claim tasks or to communicate the status of pending
tasks. Do not edit this document without consent.
The release procedure is divided up into 5 steps:
* Scheduling phase
* Stabilization phase
* Tag'n'build'n'test phase
* Release phase
* Post-release phase
During the release process there are several *special roles*: the
release coordinator, the packager and the communication agents.
The _release coordinator_ orchestrates the different people -
developers, marketing, website - working on the release. He/she
maintains this list of tasks, keeps an eye on the status and is
responsible for making the release a smooth procedure. The function
does not give any additional privileges over the other developers -
the release is a team effort - *except* in the tag'n'build'n'test
phase, where he/she is in the position to 'veto' a build.
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.
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.
== Scheduling Phase ==
* Appoint a release coordinator
* Make a rough evaluation of the pending tasks
* Set up a time frame for release
* Divide the remaining tasks
* Think of a 'blocker' policy, e.g. when are bugs blockers?
* Define what exactly is released: cd image? vmware image? qemu image? source?
== Stabilization Phase ==
* Create weekly(?) reports on the progress
* Appoint the package builder (and perhaps a backup package builder)
* Devise a proper way to test the build (goal: get it working on as
many machines as possible)
* Write up the initial Release Notes and build instructions
* Write up the 'end-user' instructions
* Do something with a supported hardware list?
== 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
== Release Phase ==
* Publish announcement
* Send press-releases
* Make sure end-user documentation is up to date and can be easily found
* Make sure the website can handle the requests
== Post-release Phase ==
* Keep a list of reviews, interviews or other publications as a
response to this release
* Add a note to the Trac ticket reporting to discourage random people
to request enhancements (if necessary)
Other related posts:
