[haiku-development] To do for alpha 1
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 13 Aug 2009 11:23:43 +0200
Hi!
I told you I would be back with more to arrange.
Immediate tasks:
* Find a build maker (and a backup build maker)
* Sketch up release notes
* Agree on schedule
Long version. First and foremost I hope that there are volunteers for
the position of build maker. Ideally it would be someone making builds
for a long while (where are the current alpha1 images produced?).
Tasks are:
* Determine the best build platform. (R5, dano, linux, Haiku itself?)
* Make images in all three variants (emulator, CD-rom, usb key)
* Incorporate feedback from the test audience.
* Make regular builds until release.
Secondly, there are many things that already work, but also some that
might not work like R5 (by design or just not yet implemented), as
well as that there are pieces of hardware not supported. I suggest we
make a short list of release notes to highlight the most important
things that work, and the things that will not work.
I have set up a wiki page at http://dev.haiku-os.org/wiki/R1/ReleaseNotesAlpha1
Feel free to jot down any notes you might think are important, we can
rework them before the release into a nice document that we might even
decide to ship with the images.
Inspiration from:
http://www.kde.org/announcements/announce-3.3.php
http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/0.11
Finally, I will have a separate thread about voting for the release schedule.
Those were all the pressing matters for now.
Niels
P.S. My previous release schedule is pasted below. We are currently in
the stabilization phase.
== Stabilization Phase ==
* 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
== 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:
