Re: GOP-PROP 12: keep master in ready-to-release state (probable decision)

[David Kastrup]

"Trevor Daniels" <address@hidden> writes:

> Graham Percival
>
>> Developers doing medium-large fixes: examples include beam
>> collisions, music function rewriting, Flag grobs, etc. All this
>> work should go on separate branches (e.g. dev/flag-grob,
>> dev/scheme-music-functions). Once the code is merged, the branch
>> should be removed. People can still use dev/myname instead, but I
>> think that naming these branches after the feature (or bugfix)
>> will be more clear.
>
> How would this code be reviewed?  Do you envisage still
> uploading to Reitfeld?  Would this be before pushing to
> dev/* or after?  I still think this is a complication too far.
> Certainly it needs more thought and comment from the 'big'
> developers before being adopted.

It is a compromise between the damage and the good developers manage to
do.  The higher the number of developers, the more important it becomes
to avoid damage, since damage blocks everybody, and good initially helps
only a single application.

I have not exactly been the paragon of damage avoidance lately.  Part of
the problem is a quite old single-core development system making it very
expensive to do a full check, particularly on small changes.  Another
part of the problem is working on several interlocking changes with
related features: it does not make sense to write independent
documentation for interlocking features, and it is not really feasible
to create independently working reviews, so I try to flush out the base
work rather sooner than later in order to make it possible to let the
work on top be reviewed at all.

Obviously, I have not yet found a balance in the current development
process where I don't turn into an annoyance.  A staging branch might be
a step in the right direction.

> My preference is for a single staging branch.  Major patches would be
> pushed there rather than to master after a successful Reitfeld review,
> and only cherry-picked to master after successful tests (eg doc build)
> by someone authorised to do so.

I am not sure cherry-picking is the way to go.  The main point of a
staging branch is that you can do a full doc and reg test for a bunch of
changes together.  When cherry-picking, this becomes more difficult.
Basically a staging master would then to have to cherry-pick to his
private staging branch (tracking origin/master), make full builds and
verifications, then push (only fast-forward!).  Afterwards rebase the
public staging branch on master and push, so that all committed changes
will no longer be present.

Hm, not all that bad.

-- 
David Kastrup