[haiku-development] Re: Haiku R1A4 Postmortem

  • From: luroh <lurohh@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 9 Dec 2012 16:10:36 +0100

On Sun, Dec 9, 2012 at 3:07 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> On 12/09/2012 01:40 PM, luroh wrote:
>>
>> Axel Dörfler wrote:
>>>
>>> On 12/09/2012 02:54 AM, luroh wrote:
>>>>
>>>>
>>>> I agree that the final decision belongs with the RM. It is his branch
>>>> and his job to communicate what goes in and what stays out. Now, if
>>>> he's unable to spot undesired commits in his own branch, I don't see
>>>> why we should trust him to pick all good ones from trunk.
>>>
>>>
>>> It's a matter of "Too many cooks..." - if there is only a single person
>>> responsible for the branch, letting other people work on the branch
>>> primarily takes away his responsibility.
>>
>>
>> No, this does not take away his responsibility to manage the branch.
>> Having only the RM commit to a branch is just one way and one aspect
>> of managing a branch.
>
>
> With your process the only option of managing the branch for the RM is to
> retroactively revert commits.

I don't understand why you keep saying that. I'm merely proposing that
it shouldn't be the responsibility of the RM to commit to branch, we
even agreed earlier that a fix could be staged in trunk or elsewhere
if need be before getting committed to branch by its developer.
Reverting commits would not be the only option for managing a branch.

> In your previous mail you suggested that this
> is an easy thing to do. That might be true technically. However, it is not
> psychologically. It's pretty much the same as with a feature being harder to
> remove than not admitting it in the first place. It would take a real badass
> RM to radically revert every commit that doesn't strictly adhere to the
> branch policy at that time.

Just like with regular trunk development, a reason and a gentle
"please revert" usually does the trick. No change here.
Now, on the odd chance that a developer commits something bad and then
goes AWOL, the RM has the option to revert the change.

>>> While that also results in less work for him, it may also result in a
>>> poorer
>>> release.
>>
>>
>> I see no evidence for that. It borders on wishful thinking and
>> preconceptions that a single person would do a better job in this
>> respect than a team managed by a single person.
>
>
> As written above, I think with the everyone commits to the branch process a
> lot more stuff will end up in the branch that shouldn't.

Without oversight, yes, probably. Luckily we have an RM to manage the branch.

> Anyway, this is all about the how stuff gets to the branch. The arguments
> are: less work for the RM vs. more control of the branch. However, you have
> been ignoring my argument regarding what gets committed to the branch.
> You're advocating that things get committed there first and be tested
> afterwards.

Like I replied to Axel, it's of no importance where things get
committed first. I'm advocating that testers should be able to report
bugs in branch and test fixes in branch. Currently they can not. We
should stop being afraid of developing fixes in branch.

> This is not recipe for continuously improving the quality of the
> branch.

On the contrary, reporting and testing in branch is indeed a recipe for quality.

> In order to compensate the RM would have to monitor the state of all
> commits and their corresponding test results to be able to revert the ones
> that didn't improve things or made them worse. Doing that consequently is
> probably much more work than just cherry-picking commits that have been
> cleared in the first place.

Well, the problem with that reasoning is that your choice doesn't
exist when we have people reporting on the branch but committing the
fixes to trunk. A trunk that we both agree could heavily deviate from
branch, which in turn could require porting.

>>> So I think having a single person responsible, and carrying out most of
>>> the
>>> work is desirable. Of course, if we don't manage to find someone (we even
>>> have the funds to sponsor such a position), we'll have to find a
>>> different
>>> way.
>>
>>
>> So the condition for considering a change would be if we fail to
>> recruit an RM to be responsible for the release and to do most of the
>> work himself. I accept that position but submit that there is a
>> benefit to us being proactive in this regard instead.
>
>
> Er, if we don't find a RM than your approach doesn't work either, since it
> requires a RM. :-)

Absolutely, and as I believe you understand, I'm trying to increase
our likelihood of finding one.

>> I fully agree that trunk should be kept as stable as possible at all
>> times.
>> My point is that my proposed change would free up trunk for regular
>> development during the release cycle.
>> Now, Ingo claims that is already the case, while at the same time
>> hinting that it's really not since it increases the burden of the RM
>> to merge to branch.
>
>
> I apparently failed to bring my point across. Your proposed change does not
> free up trunk for regular development anymore than the current process
> already does. Large changes in the trunk will cause the same overhead in
> either case. Either due to back-porting to the release branch or
> forward-porting to the trunk.

Apparently, you are not the only one failing to come across, I'm
obviously just as guilty.
Firstly, let's establish that trunk health is not the responsibility
of the RM. Trunk health is already taken care of sufficiently well by
everyone, and that's even without having someone responsible for
managing it.
Secondly, yes, large changes in trunk will cause overhead - but not
for the RM, as is currently the case.

> In either case the trunk is and was free for development in principle. We
> had no strict policy to avoid development in the trunk. It was merely a
> convenience to postpone merging larger features (like the x86-64 port),
> since there was no urgency to get them into the trunk and it would avoid
> potential conflicts.
>
> Anyway, again, there's no difference in this respect between the current
> process and your proposed change.

There is a distinct difference and you even exemplify it by mentioning
x86_64. With my suggestion, x86_64 could have been merged the same day
we branched R1A4, without causing any problems whatsoever for the RM
and his branch.

- luroh

Other related posts: