[haiku-development] Re: Haiku R1A4 Postmortem
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 08 Dec 2012 21:00:36 +0100
On 12/08/2012 05:41 PM, luroh wrote:
My overall idea here is to bring our release process more in line with
our regular development process, which over the years has developed
into something that is known and works fairly well, given that we are
a volunteer based project. Releases are unique yes, but in my opinion
not very special.
Currently the process is for everyone to continue to commit to the trunk
as usual while the release manager cherry-picks commits for the release
branch. Your proposal would have everyone mess with the release branch
and also cherry-pick commits to the trunk. To me the latter is
significantly less in line with the usual development process.
I don't know the release process of many other projects, but those I
know basically do it the same way as we do: One person is the gate
keeper for the release branch while others continue to work in the trunk.
Ingo Weinhold wrote:
On 12/07/2012 08:53 PM, luroh wrote:
1) Stop merging to branch. Fixes for the branch, along with any
features approved by the RM, should be committed to the branch by the
individual developers during feature freeze, not by the RM. If the
fixes are suitable for trunk as well, fine, the developers can go
ahead and merge them to trunk, but the health of the trunk is not the
responsibility of the RM.
I disagree. Instead of one person who knows the state and is in charge of
the release branch you'd have a dozen developers messing with the branch.
It's almost guaranteed that stuff gets committed there accidentally and
while it reduces the burden of one person it requires everyone to deal with
the release branch instead.
It would remain the RM's responsibility to be in charge of the release
branch; monitoring it, reminding developers that we are in feature
freeze, revert if needed, etc. Managing a branch shouldn't mean doing
everything yourself. Having more eyes on the branch is desirable and
reducing the burden of the RM is a good thing.
From my experience managing the alpha 2 branch, the burden of
cherry-picking (or back then with SVN: merging) trunk commits isn't a
particularly big one. Unless there are conflicts, it's a matter of a few
minutes with some tool support (a simple script). The more important
task is to decide which commits to pick for the release in the first
place. IMO it is a good thing that the final decision is the release
manager's and having everyone commit to the release branch is
counterproductive in that respect.
Please note, that I'm not saying the release manager should be the only
one ever being allowed to commit to the release branch. E.g. if a patch
requires more involved back-porting, the release manager can ask the
respective developer to do that -- prepare the commit in a public clone
or even directly commit to the release branch. But having everyone
commit to the release branch in the first would leave the release
manager only the option to retroactively revert commits.
As a side benefit, this frees up trunk for
non-release related development, instead of keeping it in a painful
indefinite semi-freeze.
There's nothing that prevents continuing development in the trunk anyway. It
just makes porting fixes back to the release branch easier when no huge
changes happen in the meantime.
You are in agreement with my statement here. Trunk is effectively
sentenced to limping along until the release is out.
Well, it's merely a convenience, not a necessity.
But applying fixes to the release branch
first doesn't improve the situation, since then porting the fix to the trunk
would be where the additional work is required.
So basically no change, work wise. But we reduce the pain of the RM
and the process better resembles our proven development model.
Yes, basically there's no change work-wise. Yes, the RM would have a
little less work. No clue, why that would resemble our development model
any better.
This all would lead to...
...better testing. Currently, a user reporting a problem in the branch
will get a fix committed to trunk(!), which can lead to catch 22
situations; the fix won't get merged to branch unless verified OK,
which the user can't do, since he's only fed nightly branch builds.
But isn't the difference only a policy question? Essentially you're
proposing that any potential fix is applied to the release branch. The same
can be done when the fix was first committed to trunk.
Not sure what you mean here by policy question. What would be the
point of having the RM merge untested fixes into branch?
Your concern is that untested fixes need to be committed to the release
branch. That's just the policy *what* is committed to the release
branch. The policy *how* those fixes get there is completely orthogonal.
So, if we decide that untested fixes should be committed to the release
branch, this can be implemented with our current process just as well as
with your proposed change that every developer commits to the branch.
Anyway, my argument still stands:
I find neither a good
approach, since it changes the nature of the release branch. It would no
longer become more stable with each commit.
Anyway, the real problem is the disabling of the nightlies for the trunk.
Its intention was to give more exposure to the branch, but as is apparent
now it has undesired side effects and should probably not be done.
No, I don't agree that's the real problem and I definitely don't think
it's any kind of solution to direct even more focus to the trunk
during the release cycle.
Is that an actual issue in practice? As long as we mainly advertise the
release branch nightlies I don't really see a reason for that.
CU, Ingo
Other related posts:
