On 02.06.2014 23:46, PulkoMandy wrote: [...]
On the release process, I would like to lock commit access to the trunk, and have all changes go through review on gerrit before they are merged.
I don't see the connection. I'm sure gerrit can as well be used for reviewing change sets already pushed to master (and cp them to the release branch). Locking down just causes developers to keep sitting on change sets that aren't meant to go into the release.
This would allow for a simpler workflow than what we used for previous releases, and could be made permanent to keep the trunk in "releasable" state at all times.
Sure, if you have a good plan where to get money for hiring a handful of full-time developers permanently, so all the necessary patch reviewing actually happens (in a timely manner).
[...]
So, things would happen in this order: 1) create tickets for the alpha5 blockers 2) solve the tickets 3) branch the release 4) have a testing run on the image built from the branch 5) fix only the most critical issues: failure to boot on most machines, repeatable KDLs. Other issues get an entry in the "known problems" of the release notes
I'd go by impact factor (on stability) rather than severeness. As long as all blockers are addressed, that is. And obviously there should be a reasonably long testing period after the fixes.
6) launch the release
CU, Ingo
