[haiku-development] Re: Haiku R1A4 Postmortem
- From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
- To: Haiku Development <haiku-development@xxxxxxxxxxxxx>
- Date: Sun, 9 Dec 2012 20:31:11 +0100
On Sun, Dec 9, 2012 at 8:15 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> 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. 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.
The difference is of course that they have many more developers and
contributors, and a different target audience that has higher
expectations from their stable releases.
Rules and procedures are made to solve problems. I am not quite sure
what problem we are trying to solve. In fact, the role of the release
manager itself is currently problematic as it takes away
responsibility of the developers in testing their own dogfood. Instead
interactions with the alpha branch get reduced to a +alpha4.
Again, having a strong and controlling release manager probably makes
sense in the world of professional software development, but as far as
I am concerned Haiku should be allowed to be a bit messy, to be a bit
experimental, and we have to figure out what works for us.
My dream scenario is that we prepare the next release in the trunk and
force every developer to focus on the quality of the code and leave
their cool new features in their own branch until after the release.
[I am realistic though, I argued for this before and nobody was happy
;-)]
But I suggest at least next time locking down the alpha branch only
for the last 1-2 weeks and before that let everybody be responsible to
committing as many patches as necessary to make it stable. Releases
should be our joint responsibility.
N>
Other related posts: