[haiku-development] Re: Haiku R1A4 Postmortem
- From: chrisjones@xxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 7 Dec 2012 01:12:15 -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
Hi Alex. All of the above sounds reasonable and sensible enough to me.
And now might be a good time to post this link.
http://www.unixmen.com/haiku-os-a-new-kind-of-operating-system/
I am a Technical Writer and this is an article I wrote for Unixmen.com on
the latest Haiku build. Please read my article and let me know your
thoughts.
Regards
Chris Jones
Other related posts:
