Hi, > You tell us the current release workflow is too much work and to fragile. What I would like to do is make release less effort and try and reduce the number of release candidates and release more frequently. IMO that's the best way to reduce the workload on the release manager. That and sharing the role about a bit :-)
> We suggest way to reduce the workload What you suggest may reduce the workload on the release manager (I'm not 100% sure there and I've done it a few times) but would increase it overall. Better to keep it simple IMO. > I sure hope you don't expect us to vote +1 (binding) within an hour of > calling the VOTE, no matter the current condition of the codebase ;-) Of course not. > 1) a few day before cutting the release branch: alert everyone that if > they want their contributions in the release, they should push them to > 'develop' Good suggestion. > 2) once all contributions have landed, cut the release branch; switch > all Jenkins jobs and Mustella runs to 'release'; leave the release > branch alone for 2 days so Mustella can be run in all configs. Wouldn't it be better if we didn't have to manually switch all of the Jenkins jobs? And then switch them back again after the vote? Less steps the better, we have already over complicated things. eg what use is trunk currently other than to cause the release manger merge issues? It is even tested? Are we 100% confident if we checked out of trunk we get the last released working version as opposed to the tagged release? (As aside I know but we keep seem to be adding more process not less is the point I'm trying to make). > 3) if and when the all lights are green (no failing tests, all builds > correct), cut RC 1 and start the VOTE, preferably around a Wednesday - > that way there are a couple of work days and a weekend ahead, which > would allow both the worktimers and the weekenders to participate Seems reasonable and in perhaps means more involvement but it does prolong each release cycle by around 4 days to a minimum of a week and that's my concern. Say you go through 4 or 5 release candidates (not unusual), that's probably a month and 1/2 that's now passed and in that time changes in develop will have gone untested. And who then fixes the issues in develop/how do you know what checkin caused any issues when you manually switch the jenkins jobs back to develop? > I really think this will cut down significantly on the work of the > release manager, as there will be a lot less RCs. How? Having tests passing doesn't mean any less RCs going on previous releases. Thanks, Justin
