Re: plan for branching

[Jonas Hahnfeld]

Am Dienstag, den 13.10.2020, 15:38 +0200 schrieb Michael Käppler:
> Am 13.10.2020 um 15:11 schrieb Jonas Hahnfeld:
> > With the localization issues hopefully resolved and no objecting
> > comments to the last thread, I think we should go ahead and create
> > stable/2.22, with release candidates (2.21.8x) on the road to 2.22.0.
> > 
> > After creating the branch, I will (unless somebody doesn't want me to
> > do this and volunteers to do the work; see also below):
> >   - bump master to 2.23.0, in preparation for the next cycle;
> >   - bump stable/2.22 to 2.21.80, in preparation for the first release
> > candidate;
> >   - merge and / or forward the translation branch to stable/2.22.
> > 
> > As a result,
> >   - release candidates are cut from stable/2.22;
> >   - master is open again for feature development etc., eventually
> > released as 2.23.0 after 2.22.0 is done (note that it would be helpful
> > to avoid large-scale changes that complicate the following points);
> >   - fixes are developed, reviewed, and merged to master via the usual
> > countdown cycle and cherry-picked into stable/2.22 once landed;
> Sounds good. But my knowledge about these things is very limited, so
> my opinion is possibly not that well-grounded...

Neither is mine, as I haven't been around when the last branch was
created. The list comes from observations of the git history, mailing
list archives, and knowledge of procedures in other projects.

> >   - the same goes for the English documentation, which may be cherry-
> > picked into stable/2.22 if applicable;
> >   - in contrast, translation targets the stable/2.22 branch to restrict
> > the documentation to what's in there; I will try to cherry-pick those
> > commits to master to avoid a similar situation we had after 2.20.
> Did I get this right:
> * _Fixes_ for the English documentation are applied to master and
> cherry-picked to stable/2.22
> (Would this apply for restructuring work like the recent CG edits, too?
> Or would they not be cherry-picked?)

Any work on the English documentation happens in master, but only
commits relevant to 2.21.8x and 2.22.0 are picked into the branch. This
may well include the CG edits, unless we only want them to appear with
2.23.0.

> * 'master' will not be merged into 'translation' (and vice versa) until
> 2.22.0 is out, instead 'stable/2.22' will
> be regularly merged into 'translation' and back. (Rationale: Do not let
> translators spend useless work on
> translation documentation for unstable features in 'master' that are in
> flux?)

Apart from the time effort, translation usually seems to happen per
file or per manual. It would be unfortunate to advertise something in
the (translated) documentation that is not available as of 2.22.0, but
taking only parts of a commit is just too much work IMO.

> * You will cherry-pick work in 'translation' during the upcoming period
> (before 2.22.0) to master that the work
> does not get lost

Mostly yes. Putting that burden onto the translators seems unfair, and
merging all changes after the stable release was a pain this time. I
hope that picking the changes continuously proves to be manageable.

signature.asc
Description: This is a digitally signed message part