[haiku-development] Re: Haiku R1A4 Postmortem
- From: luroh <lurohh@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 10 Dec 2012 20:01:19 +0100
On Mon, Dec 10, 2012 at 3:49 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
>> Am 10.12.2012 um 10:11 schrieb Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
>>> I'd be willing to volunteer as RM for our next release to try that out
>>> for real
>>> if we can agree on those or similar terms.
>
>
> Yippee! :-)
Yay, I'm sure you'll regret it, but thanks! :-)
I'm butting out of this discussion for a while, I just wanted to clear
a few things before I leave.
Firstly, Ingo, I'm sorry for becoming upset with you earlier. Having
thought about it today, I think I owe you an explanation as to what
ticked me off in the FreeBSD discussion.
I believe you were in your analytic mindset, connecting dots, honestly
thinking, "hmm...they have delegated branch commits rights to the
developers but they also conduct a review before accepting commits".
In your eyes, that looked reasonably similar to our current process.
Me, I was coming from a direction of trying to, among other things,
distribute the workload. When looking at the FreeBSD process, I saw
three distinct roles, an RM overseeing the branch and communicating
the policies, developers responsible for getting their commits to land
on branch, and finally a team of reviewers. To me, that was (and I
think still is) dissimilar to our current process, where we shove all
of those responsibilities and more into one person.
Anyway, I didn't come here to flog that horse again, I now think I
understand how you came to your conclusion and I respect that.
Secondly, and this is a general reminder to everyone including myself;
it's sometimes easy to forget that we are a volunteer based project.
We can wish for a short release cycle, for patches to be reviewed, for
a blocker bug to get fixed, for more frequent releases, etc. But, we
can't just count on it. Our release process must take this into
account or misery will inevitably follow. Of course, you all know this
already.
Thirdly, I noticed someone mentioning having a trunk better prepared
for branching. Fixed release cycles, or at least announcing branching
months in advance, providing a predictable framework to work within
for developers and RMs, could possibly be beneficial here. The thought
has likely crossed your minds already, I'm just throwing that out
there, it's not a drum that I will be beating relentlessly...for now.
;-)
Fourthly, I am grateful for having had a chance to take part in this
discussion, it has touched on many things I have been thinking about
for quite some time now.
Fifthly, I'm out. Thanks!
- luroh
Other related posts:
