[haiku-development] Re: Haiku R1A4 Postmortem
- From: luroh <lurohh@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 9 Dec 2012 20:55:18 +0100
Ingo Weinhold wrote:
> On 12/09/2012 04:10 PM, luroh wrote:
>>
>> 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:
>>>
>>> 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.
>
>
> I must have missed that. I guess then we only disagree on the "if need be".
> For me that need is practically always with rare exceptions. :-)
For me, the need is the same as in trunk, plus whatever additional
requirements are in force as communicated by the RM.
>>> 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.
>
>
> The thing is that it will reverse the power structure. Instead of a
> developer having to convince the RM that a commit should be picked for the
> release despite the RM's concerns, the RM would have to convince the
> developer. The likely result is that the RM will let more things slip
> through than they would have otherwise.
>
> As Axel writes, a developer might not be the best judge whether their own
> commit should be in the release ("Feature freeze was only two days ago and
> it's just a small feature... and sooo useful!"). Unlike the rare reverts in
> regular trunk development, I would expect disagreements on whether some
> commit should make it into the release branch to happen way more often.
As I mentioned in my reply to Axel, I see no evidence of this. We are
good a self-policing, some even better than others! :-)
>>> 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.
>
>
> The mere existence of a RM doesn't help much. The person must also be put in
> a position to work effectively. Having only retroactive powers and being
> under a certain pressure to rectify any actions is suboptimal, IMO.
Not just retroactive powers. It is the RM's job to codify and
communicate his policies, ideally well before his branch is even
created.
>>> 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.
>
>
> Sure, as long as it isn't the release branch. I would suggest a staging
> branch for the release branch, but I don't quite see how it would be much
> different from the trunk.
[1] Remember, trunk should be allowed to be seriously out of sync with
a release branch. Thus, testing in trunk may be of limited value if
the fix requires heavy porting before it can land on branch.
Personally, I likely wouldn't oppose the idea of using a staging
branch, if so communicated by the RM.
>>> 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.
>
>
> Reporting and testing, yes. Opening it for all untested patches, no.
I hope my answer below covers your question.
>>> 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.
>
>
> What's wrong with testing and reporting on the branch and, when a particular
> problem has a fix in the trunk, test whether it is really fixed in the
> trunk? AFAIK the only reason why this has been a problem was that the trunk
> nightlies were disabled.
Besides further diluting any interest in the branch by providing
nightly trunk builds, there is [1] above.
>>> 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.
>
>
> Yeah, I just don't think this approach is helping. It only reduces the work
> load of the RM a bit by avoiding the cherry-picking. As written before I
> don't consider that a lot of work anyway. It's the staying on top of
> everything -- particularly tracking and understanding the potential commits
> for the release -- that is the main work. I doubt that anyone wouldn't
> volunteer for the RM role just because of the cherry-picking. And if so,
> they probably haven't understood the role entirely.
Right, the idea is to also off-load the RM by removing his obligation
to review everything himself. We have for years been doing that fairly
successfully in trunk.
>> 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.
>
>
> OK.
>
>
>> Secondly, yes, large changes in trunk will cause overhead - but not
>> for the RM, as is currently the case.
>
>
> As written before, if certain commits require non-trivial back-porting work,
> the RM can just as well delegate that to the developer in question.
Yep. We have agreed on this before, and I believe we still do. In
fact, that is one of my core points, the RM should not be the one
merging to branch.
>>> 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.
>
>
> See above.
I must be missing something since I honestly can't tell why you can't
see the difference. Anyway, since it's seemingly not a point of major
contention for this discussion, I move that we skip trying to
understand each other's position here.
- luroh
Other related posts:
