On Dec 9, 2012, at 12:28 PM, Stephan Aßmus wrote: > Hi Luroh, > > let me try to phrase what I think you are proposing in my own words and you > tell me if I understand you correctly? > > Trunk seems to be mostly in good shape, without anybody being particularly > responsible for it. The team self-manages this, random people review other > peoples code, point out problems or tell them to fix stuff. Or people follow > up their own commits ones they realize a mistake or maybe they have feedback > from testers. > > What makes the release branch different? The goal of both trunk and a release > branch seem to be that they are as stable as possible. Obviously it is ok for > trunk to be unstable for the short term. It's the goal of the release branch > to gravitate towards release quality. > > The questions seems to be, why do we need a release manager? And if we do, > how can we put less burden on him and spread the responsibility more among > the team? > > I think I follow your logic, if I got you right, and also don't understand > the reasoning why the "responsibility" of a release manager should mean that > only he gets to commit to the release branch, by understanding each and every > important commit that potentially increases the quality and then additionally > having to actually perform the commit. > > The responsibility of the RM could also mean that he has some sort of final > say. Please revert this or that… please test on this or that hardware… > someone who simply stays on top of things, keeps track of outstanding issues. > > Do I understand you correctly? If we manage to keep trunk in good shape for > the majority of the time, why should we work so radically different preparing > a release? The release management process involves coordination of a lot more than just commits, which makes this approach difficult for a release manager. If there are release candidates, or testing procedures, or other processes that must occur prior to a final release, the release manager needs to be able to lay down a code freeze and have final control over merging in of changes to avoid the introduction of any issues. At that point, if developers are free to just merge what they think is right, it creates more work for a release manager; they have to monitor the changes, potentially back them out, or reset the release process and issue another set of release candidates, schedule more testing, etc. Given that the cost of dealing with unexpected changes will fall on a release manager, I think it makes sense to adopt a process where you need the release manager's approval to merge in new changes after a code freeze has occurred, as well as careful additional review by more engineers. There's a much higher risk to merging in changes right before a release, and as such, I think it deserves higher scrutiny as compared to standard development practices. FreeBSD has a very solid process for handling release engineering, with the additional benefit of it being well documented; I think it could be worth cribbing from their experience: http://www5.us.freebsd.org/doc/en_US.ISO8859-1/articles/releng/index.html -landonf