[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stable/2.22 has branched; master is 2.23.0

From: Jonas Hahnfeld
Subject: Re: stable/2.22 has branched; master is 2.23.0
Date: Sat, 17 Oct 2020 10:17:23 +0200
User-agent: Evolution 3.38.1

Hi Carl,

Am Freitag, den 16.10.2020, 12:46 -0600 schrieb Carl Sorensen:
> On Fri, Oct 16, 2020 at 11:41 AM Jonas Hahnfeld <>
> wrote:
> > 
> > So master is 2.23.0 and usual development can resume, with the
> > pleading to avoid disruptive changes that make picking harder than
> > necessary. Fixes should also go to master and I'll pick them to the
> > branch. If you really need to do that, please use 'git cherry-pick
> > -x' to record the original hash.
> When do we stop worrying about cherry-picking and feel free to make
> disruptive changes again?  I'm not asking because I have something in
> the queue;  I'm just trying to understand the policy.

I don't think there's a really good answer to that question right now:
As long as stable/2.22 is active and point versions might be released,
any change in master will cause some amount of work. What I'm asking
for is to reduce the number of (large) changes that complicate picking
more than necessary.

For example, automated formatting touches lines in a number of files
with a somewhat spread diff. In contrast, significant work on a
particular part of the code (Dan's changes to volta, Owen's work for
SMuFL) is very focused and should happen IMHO. Sure, it won't be easy /
possible to pick fixes across these changes, but I don't think it makes
sense to block any feature development while stable/2.22 is active.
After all, the point of branching was to unblock development.

So the short answer is: it depends. And I expect this to become less of
a concern over time as the fixes picked to the branch decreases.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]