[haiku-development] Re: Haiku R1A4 Postmortem

  • From: Landon Fuller <landonf@xxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 9 Dec 2012 13:25:31 -0500

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

Other related posts: