Hi, > Le 24 août 2020 à 13:46, Jonas Hahnfeld <hah...@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 <hah...@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?