Alexander von Gluck IV wrote: > I've been working on the mentioned PDF.. here is the first draft: > http://goo.gl/Vg7zv > > Thoughts? Well. Firstly, well done on the release(s). You stepped up and picked up the slack and we're all very much grateful for it. As a mostly innocent bystander observing our release methodology over the years, I have condensed a list of notes that I have kept around into three main suggestions for lessening the load on the RM and to improve testing. In order of importance: 1) Stop merging to branch. Fixes for the branch, along with any features approved by the RM, should be committed to the branch by the individual developers during feature freeze, not by the RM. If the fixes are suitable for trunk as well, fine, the developers can go ahead and merge them to trunk, but the health of the trunk is not the responsibility of the RM. As a side benefit, this frees up trunk for non-release related development, instead of keeping it in a painful indefinite semi-freeze. This all would lead to... ...better testing. Currently, a user reporting a problem in the branch will get a fix committed to trunk(!), which can lead to catch 22 situations; the fix won't get merged to branch unless verified OK, which the user can't do, since he's only fed nightly branch builds. There are several examples in Trac of this happening, causing unnecessary delays. Additionally benefiting the release, more people would be drawn into branch testing, as there would be a reduced need for staying on trunk for the "latest and greatest". Once code freeze happens, only fixes approved by the RM get committed, still by the respective developers. 2) Branch buildtools too. This has the benefit of not blocking Haiku trunk development while keeping the release branch protected from any potentially invasive changes. 3) Keep the ISO and Anyboot images < 700 MB from day one to let the testers burn them to CDs. - luroh