On 12/07/2012 08:53 PM, luroh wrote:
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.
I disagree. Instead of one person who knows the state and is in charge of the release branch you'd have a dozen developers messing with the branch. It's almost guaranteed that stuff gets committed there accidentally and while it reduces the burden of one person it requires everyone to deal with the release branch instead.
As a side benefit, this frees up trunk for non-release related development, instead of keeping it in a painful indefinite semi-freeze.
There's nothing that prevents continuing development in the trunk anyway. It just makes porting fixes back to the release branch easier when no huge changes happen in the meantime. But applying fixes to the release branch first doesn't improve the situation, since then porting the fix to the trunk would be where the additional work is required.
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.
But isn't the difference only a policy question? Essentially you're proposing that any potential fix is applied to the release branch. The same can be done when the fix was first committed to trunk. I find neither a good approach, since it changes the nature of the release branch. It would no longer become more stable with each commit.
Anyway, the real problem is the disabling of the nightlies for the trunk. Its intention was to give more exposure to the branch, but as is apparent now it has undesired side effects and should probably not be done.
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.
+1
3) Keep the ISO and Anyboot images < 700 MB from day one to let the testers burn them to CDs.
+1 CU, Ingo
