Re: branching stable/2.22?

[Jean Abou Samra]

Hi,

> Le 24 août 2020 à 13:46, Jonas Hahnfeld <hahnjo@hahnjo.de> a écrit :
> 
> Am Montag, den 24.08.2020, 12:56 +0200 schrieb Jean Abou Samra:
>> Hi,
>> 
>>> Le 24 août 2020 à 08:30, Jonas Hahnfeld <hahnjo@hahnjo.de> a écrit :
>>> 
>>> Am Sonntag, den 23.08.2020, 23:44 +0200 schrieb Jean Abou Samra:
>>>> Maybe we could try to release 2.20.1 with Python 3?
>>> 
>>> That would mean porting 50+ commits which sounds like a bad idea and
>>> even gets worse because of the reformatting in master. The latter
>>> implies that any bug fix made in master will result in merge conflicts.
>>> Plus I don't understand the proposal if you're at the same time saying
>>> that the scripts are fragile. By that logic, why would we backport such
>>> extensive changes and claim they're stable?
>> 
>> Right, I was oblique: the scripts are fragile at present, so branching 
>> release/2.22 now is no good in my opinion, but hopefully we can stabilize 
>> them faster than we stabilize LilyPond as a whole, and have that in 2.20.1 
>> or 2.20.2.
>> 
>> Can you explain why porting 50 commits from master to 2.20 is a bad idea?
> 
> I think it's a bad idea because it goes against my basic understanding
> that only bug fixes should be ported a stable branch.

This situation is special anyway: we did a release that is from the start 
outdated with respect to Python support.

All I'm saying is that porting this to 2.20 would be better than releasing 2.22 
in a hurry, for the reasons that David and I mentioned. So...

> Here's the total
> number of commits in stable/2.20 since branching:
> [...]
>> If we port all Python related-commits (including the reformatting), there 
>> won't be any merge conflicts, or am I being dense somehow?
> 
> [...]
> Being the individual with the most commits in there during the cycle, I
> strongly advise against taking all of this for a minor stable release.

... so since that appears unpossible, I guess we'd just let distros drop 
LilyPond.


>> I do understand that having LilyPond 2.20.0 support exclusively Python 2 but 
>> 2.20.1 be Python 3 only feels weird. However, I value the interest of the 
>> average user more than that of packagers. Neither Python 3 nor Guile 2 is a 
>> breaking change from the user's point of view. If having LilyPond 2.20.1 (or 
>> 2.20.2) support Python 3 is not feasible, I think we should just let 
>> distributions drop LilyPond (see below). I'm not happy about it, but this 
>> is, in my opinion, preferable to making a stable release, in a hurry, that 
>> will contain more bugs and few user-facing changes.
>> 
>>>> Why Guile 2? If it's still imperfect and slower, we don't want to make it 
>>>> the default in the binaries at lilypond.org, do we? So how will the 
>>>> situation be different from 2.20? Sorry, I must be missing something 
>>>> obvious here... I don't understand you.
>>> 
>>> At least in my book, it's not about changing the default but at least
>>> making it possible for distributions to compile with Guile 2.x instead
>>> of just throwing LilyPond out.
>> 
>> Does this mean that we'll receive bug reports that won't be reproducible by 
>> others because they'll actually be related to Guile 2? In my opinion, the 
>> distributions just throwing out LilyPond is better.
>> 
>> Additionally, the sh installers are recommended by the official website over 
>> distribution package managers.




>>> I don't think we'll get testing from distributions until we declare a
>>> way to stabilize.
>> 
>> We're speaking from different points of view here: in my book, our main 
>> source of testing is our development and beta releases brought to users 
>> through installers. I mean that LilyPond 2.22 should introduce full support 
>> for Guile 2 with byte compilation, probably dropping Guile 1 support too, 
>> and we get Guile 2 testing from those who try out the betas.
> 
> I seriously doubt you'll get that for 2.22 next year.

That date was a shot in the dark intended at starting the discussion.

See also below.

>>>> Am Sonntag, den 23.08.2020, 14:59 +0200 schrieb David Kastrup:
>>>>>> I'd like to ask what it would take in principle to branch stable/2.22
>>>>>> and what others think about this.
>>>>> 
>>>>> I don't see that this is a good point of time.
>>>>> There has been an influx of badly tested changes to the build system and
>>>>> directory setup and the web pages that has to stabilise and result in a
>>>>> workable version of LilyPond. I don't see the point in branching a
>>>>> "stable" branch if there is so much in a destabilised state: you'd have
>>>>> to cherry-pick loads of stuff from the unstable branch as it comes in.
>>>> 
>>>> [Jonas] I fully agree 
>>>> 
>>>> ... and so do I (for what my opinion's worth, really) ...
>>>> 
>>>> [Jonas] and I should have been more clear that I don't expect the branch 
>>>> to happen in the next week. The point was to find out what it would take 
>>>> because just waiting for some unspoken condition to become true is not 
>>>> exactly going to happen without some effort.
>>>> 
>>>> What about scheduling the release?
>>>> 
>>>> While I do know that "Grass doesn't grow faster when you pull on it.", I 
>>>> would definitely like having a defined point in time where the stable 
>>>> release is to happen, so that everyone can focus on bug fixes before it 
>>>> happens. Sure, we aren't going to get agreement in a second about the date 
>>>> (even if not more precise than a month), but to me, having this talk now 
>>>> is preferable so as to give LilyPond development a tempo. To say it with 
>>>> other words, we've got a score to play; arguing about the tempo is better 
>>>> than starting the piece with different tempi.
>>>> 
>>>> As sort of a shot in the dark, how about planning the 2.22 release for May 
>>>> 2021, for example?
>>> 
>>> Do you mean branching stable/2.22 or releasing 2.22.0 in May 2021? In
>>> my understanding, the past process includes the release of beta
>>> versions from the branch. That makes it close to impossible to predict
>>> the final date of the stable version, and that's not the purpose of
>>> this thread.
>> 
>> I mean releasing 2.22.0 in May 2021. This is not about predictions, but 
>> objectives. I think that instead of planning each small step on the fly with 
>> no idea how the future looks like, we should settle an expected date for the 
>> release and plan backwards accordingly. Sure, there could be critical bugs 
>> that delay the actual release, but setting the expectation enables more 
>> resources to focus on the release by the time it is due to happen. In my 
>> opinion, this is the way we can avoid things like the 2.14 release that is 
>> documented in the CG.
>> 
>> So, an expected release in May 2021 would mean branching release/2.20 around 
>> January (?) and beta releases at a monthly cadence until the release is out.
>> 
>> I'm curious about what others think of that. In fact it looks like you 
>> already proposed something along these lines:
>> https://www.mail-archive.com/lilypond-devel@gnu.org/msg72997.html
> 
> And it didn't get much support. Which is why I don't see what's
> different today. Asking what it would take to branch is really the only
> sensible thing I think we could possibly agree on.

As I see it, you're asking something nobody, apparently, can give you. We need 
to create the process instead of finding it out: what do you think it should 
take to branch?

Branching means collectively commiting to creating a stable release a handful 
of months later, otherwise we get to the situation that David described in his 
last reply: the stable branch comes so far from master that features need to be 
ported to it; clearly, that's not a desirable workflow.

Whatever the option, we will need people to manage the release (yes, I could 
possibly help next summer ... though I'm afraid I'd be NOT_SMART). So, I think 
the question is essentially wether we try to plan the release now or just wait 
for the essential features we'd like in it to be implemented, e.g., full Guile 
2 support. Personally, I think it's better to plan it so hopefully developers 
will naturally organize their respective works accordingly. In this 
perspective, if full Guile 2 support is not implemented by the deadline, it 
just waits for another release. But that's just my opinion.

Cheers,
Jean

>> But David was reluctant for reasons that sound sensible. David, what would 
>> be your opinion today?