[haiku-development] Re: Haiku R1A4 Postmortem
- From: pulkomandy@xxxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 09 Dec 2012 20:33:59 +0100
> I'm totally for having a code review tool available for our regular
> development. As the alpha 2 release phase has demonstrated clearly,
> mandatory code reviews for the release process don't work for us (ATM),
> though. Not even with a full-time RM who does most of the reviews.
Actually, the problem is that the RM is alone reviewing commits on the
branch. Most activity happens in trunk. The latest bugfixes, the commit
mails with which we do peer review, and the testing of most developers.
With the proper tools and the proper workflow, we can get everyone to review
commits and vote for them. The work of the RM is then only making the final
decision on difficult commits.
We clearly have a problem in getting people involved in the release. This is
caused by a too long release cycle where the alpha branch lags behind trunk
too much, the fixes for bugs in the alpha actually going in trunk first,
before being cherry-picked, and the fact that only the RM is allowed to
commit to the branch. The result of all these factors is that all
developpers are working on the trunk, and the users have to test the fixes
on trunk. The fact that we don't provide trunk nightlies while in alpha mode
doesn't help changing the situation.
You did the work of release manager as a full-time job and it went ok. I did
it on my free time and it was really eating too much of it, leading to
mostly 1 year without serious work on Haiku from my side for lack of
motivation. Ryan even gave up before getting the release done. I think this
really shows we ask too much from the RM and not enough from other people.
We have several solutions.
* Hiring the RM to work full-time on the release for a month or two. *
This make our releases depends on one of the core devs (the RM needs commit
access) being available full-time for 2 month, at the right time to do a
release (starting off a stable enough trunk with some new features). It also
requires funding that could be spent elsewhere.
* Reducing the delta between trunk and branch *
Less commits to track and merge means less work for the RM. This can be done
by getting the release cycle shorter, delaying the branching as much as
possible. There's a risk of lowering the quality of the release by lack of
time.
Another solution is slowing down trunk development during the release stage.
This can be done by not branching and using trunk as the "release branch",
but it needs some other place to store and expose the experimental commits
for reviews. Requires a deeper rework of the workflow evenout of release
branches.
* Sharing the load of RM work between more people *
Relying on more people to do the work of getting the release done can remove
some of the stress. It may be the whole team, only 2 or 3 people, or
somewhere in between. This requires coordination from the members of the RM
team.
--
Adrien.
Other related posts:
