[haiku-development] Re: Haiku R1A4 Postmortem
- From: luroh <lurohh@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 8 Dec 2012 17:41:31 +0100
Hi Ingo and thanks for your reply.
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.
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.
>
>
>> 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.
> 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.
>
>> 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?
> 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.
- luroh
Other related posts:
