[haiku-development] Re: Haiku R1A4 Postmortem
- From: luroh <lurohh@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 10 Dec 2012 00:33:09 +0100
Ingo Weinhold wrote:
> On 12/09/2012 09:36 PM, luroh wrote:
>>
>> Ingo Weinhold wrote:
>>>
>>> On 12/09/2012 07:25 PM, Landon Fuller wrote:
>>>>
>>>> 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
>>>
>>>
>>>
>>> Sounds reasonable. And it isn't that different from our process either.
>>
>>
>> I'm sorry, but I got slightly upset by reading your statement. If
>> anything, surely you must admit that the FreeBSD process better
>> resembles my suggestion in this very thread than our current release
>> process? Let's see:
>>
>> * RM laying down the law - check.
>
> How is that different from our current process? AFAI understand your
> proposal you would mainly remove the RM's prerogative for exclusive branch
> commits, not give the RM any additional power.
Our current process doesn't involve any RM communicating any policies
for committing to his branch. And no wonder, since he is about the
only one committing to his branch. What we do is ask people to tag
relevant commit messages in the hopes that the RM can find them later
sifting through trunk, for subsequent review and merging to branch by
the RM alone.
>> * Developers committing to branch - check.
>
> After explicit approval by the RM.
Yep, which is not something that occurs in our release branches, save
for l10n updates. Granted, you pointed out this difference yourself in
your comment.
> Every single commit goes to the trunk first
I'm not saying you're wrong here, I just can't find any support for
that statement in the document linked above. From what I can tell, it
seems to apply while they are merging from trunk, until they hit their
first freeze. If they use trunk after that or some other staging area
or method, I can't tell.
>> * Joint code review - check.
>
> No clue what you mean by that point.
Bad wording on my part. What I meant was that unlike our current
process, theirs does not seem based on a single person reviewing all
changes during their freezes.
>>> A
>>> main difference is that they have a permanent stable branch, which we
>>> don't
>>> (we might consider that, maybe when starting with the beta phase). Aside
>>> from that, instead of having the RM do the merging themselves, they only
>>> have to approve of merge requests and have the developers do the actual
>>> job.
>>
>>
>> Not during their initial 15-day merge window.
>
>
> We do the same before creating the release branch.
Ok, I see what you mean here.
Since neither of us is advocating adopting the FreeBSD release
process, it may be ill-invested time discussing the finer points about
it, especially when their documentation seems a bit sparse on these
issues.
I mainly wanted to contest your assertion that it resembles our
release process by providing a few examples.
- luroh
Other related posts:
