[haiku-development] Re: Haiku R1A4 Postmortem
- From: luroh <lurohh@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 9 Dec 2012 13:40:53 +0100
Hi Axel, welcome :)
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.
> 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.
> 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.
>> for merging to a branch. However seemingly desirable, that's a policy
>> ripe with vagueness and wishful thinking. Also note that such a
>> position will have to be dealt with sooner or later anyway, since it
>> will become unsustainable once we start maintaining branches.
>
>
> Why would that be? I doubt we'll maintain stable branches for long in
> reality, and if we do, why burden us with more than point releases (ie.
> minor bug fix updates)?
> The major work on future releases should not happen in trunk, but in public
> developer repositories. The trunk should stay as stable as possible at all
> times, so that it can be released from time to time without too much hassle.
> New features should only get merged when ready.
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.
>>> Your concern is that untested fixes need to be committed to the release
>>> branch. That's just the policy *what* is committed to the release branch.
>>> The policy *how* those fixes get there is completely orthogonal. So, if
>>> we
>>> decide that untested fixes should be committed to the release branch,
>>> this
>>> can be implemented with our current process just as well as with your
>>> proposed change that every developer commits to the branch.
>>
>> True, the difference being, with my proposed change, there wouldn't be
>> a need for a policy at all since the situation would not arise in the
>> first place.
>
>
> The policy would be to first commit to the branch. That's still a policy,
> though :-)
Nope, no policy. We wouldn't care if a fix gets committed to trunk or
branch first.
- luroh
Other related posts:
