[haiku-development] Haiku R1A4 Postmortem

  • From: Alexander von Gluck <kallisti5@xxxxxxxxxxx>
  • To: <haiku-development@xxxxxxxxxxxxx>
  • Date: Thu, 06 Dec 2012 20:19:32 -0600

Good evening!

I wanted to take a few minutes to discuss some of the problems I had coordinating R1A4 which lead to the need for R1A4.1

In retrospect, I can mostly sum up my poor R1A4 planning due to the following:

* The Release Coordinator (ahem... me :) having no major software release experience - I've never been involved in the Haiku release process.. so it was all new ground for me. - I picked up the position mostly due to us slipping so much on the R1A4 timeline and the
     lack of anyone having the time to get R1A4 out the door.
 * Poor timelines defined.
- I completely underestimated the amount of time needed for extensive testing. The small testing time combined with the extremely small group of people doing testing (3) lead to the bugs that slipped in. I only have so much hardware at hand. I tested the final image on 6 machines and only saw one of the bugs, on one machine, once. (it then
     disappeared after rebooting)
 * Too much cherry picking! (mostly my fault)
- Things were very behind on the R1A4 branch when I picked up the release, and I spent 95% of the weeks before the release cherry-picking like a mad man to try and get things caught up. (which makes it hard to thoroughly review changes) In retrospect I wish we erased the R1A4 branch and started fresh after it got so behind. (giving us more time for
     proper testing)

With the items above in mind, my recommendations for the future are:

- The fork of a release branch should be no more then one week from the final feature freeze. * If something happens and we can't do the feature freeze within one week... we erase the
     branch and try again.
- 3 weeks of bug testing / fixing at minimum. Given our limited number of testers I feel
   an extended testing cycle is a requirement.
- A final 'release candidate' image needs to be advertised on the site for one week. - Once public feedback from the release candidate is received (and any final emergency changes made), one week will be provided to the buildmeister for the final version to
   be built and released.

 - Total plan: 6 weeks.

I'd like to see a fixed release cycle. (every 6 months / 1 year an alpha/beta is released, etc)

Once these topics are discussed, I'd like to put them into a 'hard' pdf release guide for future release coordinators... one problem I had was the lack of guidance on what out best practices were. (there were notes on all of this... but they seemed flexible) We do have a wiki page for notes to release coordinators and planning... but given the wiki format it bleeds over into a mess fairly quickly. A pdf seems more 'official' :)

 -- Alex

Other related posts: