>> 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 :-)
MORE releases means LESS work? IMHO if we do 2 point releases and/or one feature per year, a project like ours is in good shape. >> 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. As several people indicated, we'd like to help out with releases. Most of us don't have the cycles to do the entire release manager job, but we do have cycles to help out... >> 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). I don't mind "switching" the build and Mustella jobs. I'd have one set of copies pointing to 'develop' and another that points to the new 'release' branch. As with the general maintenance of the CI, I'd gladly take this on me as well. On your second point: you are not trying to get another SVN vs. git discussion going, are you ;-) >> 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? If that's the time it takes to do it right, than that's the time it takes. If it turns out that your worst case scenario would play out, we can set up a separate VM (as Fred suggests) and test the RCs on that and keep testing 'develop' on the current one. >> 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. Well, this all started because RC1 was cut while there were tests failing. So at least for this release, above procedure would have saved us one RC. Lastly, I'd like to +1 on the suggestion from Alex that we wait until we have active positive feedback - not a LAZY consensus - from the active committers before we cut an RC. If it takes a couple of days for 2 or 3 to answer, or if it takes a couple of pings/bumps before anyone bothers to respond, so be it. We don't have management pushing us to release, we don't have marketing deadlines nor do we have impatient customers. We should release when we're ready to release, no later, but certainly not sooner. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
