Re: 2.20.0 release coordination with translation, also Germans? (was: [translations] 2.20 and 2.21 release plans)
Il giorno gio 20 feb 2020 alle 14:06, David Kastrup ha scritto: In unrelated news, I tried my hand at translating at least the Changes file into German and am about 50% done. Anybody want to work from the bottom so that we should coordinate in order to avoid duplicate effort? I got kind of a headache so far. Hats off to people who tackle a whole translation rather than just a puny file. Indeed, it requires a strong commitment... it took me almost 10 years to translate all the manuals! Translation infrastructure is another area which could be improved. After 2.20 is out I'll try to bring it up for discussion.
2.20.0 release coordination with translation, also Germans? (was: [translations] 2.20 and 2.21 release plans)
Federico Bruni writes: > Il giorno lun 17 feb 2020 alle 22:49, Federico Bruni > ha scritto: >> I'm working on the italian update and I hope to be ready before >> Thursday night. >> > > Can we have one day delay? So deadline to push to translation branch > by Friday night? > I guess I won't have enough time to complete the update but at least I > can use some spare time tomorrow to get close to the goal. There was no fixed deadline. My goal was "this weekend", but if that makes things ugly, there is no point in not delaying some more days after the years we spent on this. In unrelated news, I tried my hand at translating at least the Changes file into German and am about 50% done. Anybody want to work from the bottom so that we should coordinate in order to avoid duplicate effort? I got kind of a headache so far. Hats off to people who tackle a whole translation rather than just a puny file. -- David Kastrup
Re: [translations] 2.20 and 2.21 release plans
Il giorno lun 17 feb 2020 alle 22:49, Federico Bruni ha scritto: Il giorno lun 17 feb 2020 alle 22:35, David Kastrup ha scritto: Jean-Charles Malahieude writes: Le 17/02/2020 à 13:25, David Kastrup a écrit : Ok, I think 2.20 is basically done and we should push it out by the end of this week. This leaves a few days for the translation team to catch up with the current state. In particular HINT HINT HINT it gives the opportunity to native speakers of languages not as meticulously maintained as the currently most active translations to at least tackle the Changes document and maybe check a few other points of the web presence. This is more addressed to people reading this announcement on the lilypond-devel list than to lurkers on the translations list, though of course the latter would be equally welcome. I've planned to merge translation into stable on Thursday night, with the French part fully updated (lots of work with Werner's indexing). That sounds great. Well yes, the indexing changes have been very recent and pretty large. If anybody else feels like their work would benefit from a minor delay, please speak up. I'm working on the italian update and I hope to be ready before Thursday night. Can we have one day delay? So deadline to push to translation branch by Friday night? I guess I won't have enough time to complete the update but at least I can use some spare time tomorrow to get close to the goal.
Re: 2.20 and 2.21 release plans
Urs Liska writes: > Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup: >> Ok, I think 2.20 is basically done and we should push it out by the >> end >> of this week. > > This is really great news! > I'm somewhat undecided whether it is a cause for celebration or not to > finally release a "stable" version after six years. But at the end of > the day I think we should praise those who have actually worked so hard > to make it happen. And all of us who benefit from that work might think > about what we can do to help bringing the *next* stable release over > the goal line in less than six years. > > I have one side remark to that, although I'm not sure if it's > appropriate to inject it into this thread. > > I haven't commented on the issue of a package loading mechanism > recently, for two reasons: I don't have any time right now, and I > thought it would be a distraction from the more pressing issues around > the build system, contribution workflow/tooling and finalizing a > release. > While it has been clear from the start that integrating a package > loading mechanism was not in question for 2.20.0, I would like to ask > if it can be considered making this go into a 2.20.x release and not > keep it on the 2.21 track as would be the natural itinerary. Doing so > (the latter) would force openLilyLib and - more importantly - > interfaces like Frescobaldi to support two alternative syntaxes of > loading packages until a 2.22 release. > So I would be glad if we could spend sufficient effort after 2.20.0 and > 2.21.0 releases to discussing, implementing, and testing a package > loading mechansim sufficiently that we can integrate it not only in the > 2.21.x but also a 2.20.x release. I don't think that would make a lot of sense since 2.21.x is the test and maturing bed for 2.22. But there is nobody forcing us to take 6 years for 2.22. Or 3.0. A fully functional package organisation system would in my opinion justify a major version number change. Also it does look like the next stable release is going to contain Guile 2+ support that is less of an abomination than what we have so far been able to provide. At any rate, I don't think it makes sense to nail down too many specifics of unreleased versions. Not if we want to end up more timely than this time round. -- David Kastrup My replies have a tendency to cause friction. To help mitigating damage, feel free to forward problematic posts to me adding a subject like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
Re: 2.20 and 2.21 release plans
Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup: > Ok, I think 2.20 is basically done and we should push it out by the > end > of this week. This is really great news! I'm somewhat undecided whether it is a cause for celebration or not to finally release a "stable" version after six years. But at the end of the day I think we should praise those who have actually worked so hard to make it happen. And all of us who benefit from that work might think about what we can do to help bringing the *next* stable release over the goal line in less than six years. I have one side remark to that, although I'm not sure if it's appropriate to inject it into this thread. I haven't commented on the issue of a package loading mechanism recently, for two reasons: I don't have any time right now, and I thought it would be a distraction from the more pressing issues around the build system, contribution workflow/tooling and finalizing a release. While it has been clear from the start that integrating a package loading mechanism was not in question for 2.20.0, I would like to ask if it can be considered making this go into a 2.20.x release and not keep it on the 2.21 track as would be the natural itinerary. Doing so (the latter) would force openLilyLib and - more importantly - interfaces like Frescobaldi to support two alternative syntaxes of loading packages until a 2.22 release. So I would be glad if we could spend sufficient effort after 2.20.0 and 2.21.0 releases to discussing, implementing, and testing a package loading mechansim sufficiently that we can integrate it not only in the 2.21.x but also a 2.20.x release. Urs > This leaves a few days for the translation team to catch > up with the current state. > > In particular HINT HINT HINT it gives the opportunity to native > speakers > of languages not as meticulously maintained as the currently most > active > translations to at least tackle the Changes document and maybe check > a > few other points of the web presence. This is more addressed to > people > reading this announcement on the lilypond-devel list than to lurkers > on > the translations list, though of course the latter would be equally > welcome. > > What does this mean for 2.21.0? I think we should aim to push it out > fast afterwards, basically a few days later at most, just to get > kinks > with webpage/versioning from 2.20 ironed out. > > I am not sure it is realistic to expect to get the translations > merged > into 2.21.0 already: because of the significant divergence > experienced > so far, I expect this to be a significant merging headache. It would > be > nice to have, but not essential: this is the unstable branch after > all. > > For more extensive changes of internals and/or syntax, I would > recommend > to let them sit till 2.21.1 before committing, assuming that we _do_ > manage to get 2.21.0 out fast. Why? 2.21.0 has by now quite > significantly diverged from 2.20.0. If something does not quite > work, > it would be nice to have a _released_ version to compare to, and > nothing > but 2.21.0 would really serve that role satisfactorily. Particularly > where problems are detected a long time after getting introduced, > having > an installable version as a reference is nice, and "it stopped > working > in 2.21.0" is enough of a quagmire already that we do not really want > to > add a lot more here. > > The size of the headache basically is commensurate with how long the > stable branch has diverged. Hopefully we manage to find some > combination of process and responsible persons next time around that > delivers faster. > > Nevertheless, I am glad we are getting there. >
Re: [translations] 2.20 and 2.21 release plans
Il giorno lun 17 feb 2020 alle 22:35, David Kastrup ha scritto: Jean-Charles Malahieude writes: Le 17/02/2020 à 13:25, David Kastrup a écrit : Ok, I think 2.20 is basically done and we should push it out by the end of this week. This leaves a few days for the translation team to catch up with the current state. In particular HINT HINT HINT it gives the opportunity to native speakers of languages not as meticulously maintained as the currently most active translations to at least tackle the Changes document and maybe check a few other points of the web presence. This is more addressed to people reading this announcement on the lilypond-devel list than to lurkers on the translations list, though of course the latter would be equally welcome. I've planned to merge translation into stable on Thursday night, with the French part fully updated (lots of work with Werner's indexing). That sounds great. Well yes, the indexing changes have been very recent and pretty large. If anybody else feels like their work would benefit from a minor delay, please speak up. I'm working on the italian update and I hope to be ready before Thursday night.
Re: [translations] 2.20 and 2.21 release plans
Jean-Charles Malahieude writes: > Le 17/02/2020 à 13:25, David Kastrup a écrit : >> Ok, I think 2.20 is basically done and we should push it out by the >> end >> of this week. This leaves a few days for the translation team to catch >> up with the current state. >> In particular HINT HINT HINT it gives the opportunity to native >> speakers >> of languages not as meticulously maintained as the currently most active >> translations to at least tackle the Changes document and maybe check a >> few other points of the web presence. This is more addressed to people >> reading this announcement on the lilypond-devel list than to lurkers on >> the translations list, though of course the latter would be equally >> welcome. >> > > I've planned to merge translation into stable on Thursday night, with > the French part fully updated (lots of work with Werner's indexing). That sounds great. Well yes, the indexing changes have been very recent and pretty large. If anybody else feels like their work would benefit from a minor delay, please speak up. -- David Kastrup
Re: [translations] 2.20 and 2.21 release plans
Le 17/02/2020 à 13:25, David Kastrup a écrit : Ok, I think 2.20 is basically done and we should push it out by the end of this week. This leaves a few days for the translation team to catch up with the current state. In particular HINT HINT HINT it gives the opportunity to native speakers of languages not as meticulously maintained as the currently most active translations to at least tackle the Changes document and maybe check a few other points of the web presence. This is more addressed to people reading this announcement on the lilypond-devel list than to lurkers on the translations list, though of course the latter would be equally welcome. I've planned to merge translation into stable on Thursday night, with the French part fully updated (lots of work with Werner's indexing). Cheers, -- Jean-Charles
Re: 2.20 and 2.21 release plans
Jonas Hahnfeld writes: > Am Montag, den 17.02.2020, 14:59 +0100 schrieb David Kastrup: > >> Yes, GUB for 2.21.0. We don't want to have another indeterminate >> backlog on unstable releases. That means that GUB needs to get switched >> over to Python 3. > > For those following along: It's not that we need to convert GUB to > Python 3, just switch the dependencies of the LilyPond spec. > >> It may make it more prudent, should we need to >> release 2.20.1 at some time, to also go to the cherry-picking nightmare >> required to bring stable/2.20 up to Python 3. > > My point of view remains: Just keep an old version of GUB around and > we're fine for 2.20.x, x > 0. In the end, it will depend on how it works out for the person creating the releases, I guess. -- David Kastrup
Re: 2.20 and 2.21 release plans
Am Montag, den 17.02.2020, 14:59 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup: > > > Ok, I think 2.20 is basically done and we should push it out by the end > > > of this week. This leaves a few days for the translation team to catch > > > up with the current state. > > > > Wohoo! > > > > > [...] > > > > > > What does this mean for 2.21.0? I think we should aim to push it out > > > fast afterwards, basically a few days later at most, just to get kinks > > > with webpage/versioning from 2.20 ironed out. > > > > > > [...] > > > > > > For more extensive changes of internals and/or syntax, I would recommend > > > to let them sit till 2.21.1 before committing, assuming that we _do_ > > > manage to get 2.21.0 out fast. Why? 2.21.0 has by now quite > > > significantly diverged from 2.20.0. If something does not quite work, > > > it would be nice to have a _released_ version to compare to, and nothing > > > but 2.21.0 would really serve that role satisfactorily. Particularly > > > where problems are detected a long time after getting introduced, having > > > an installable version as a reference is nice, and "it stopped working > > > in 2.21.0" is enough of a quagmire already that we do not really want to > > > add a lot more here. > > > > Sounds good (well, Python 3 is already in). To be sure: This also means > > we'll be using GUB for 2.21.0? I'd like to propose a new system (yes, > > *with* support for Windows) soon, but not sure that I can make it in > > the next week or so... > > Yes, GUB for 2.21.0. We don't want to have another indeterminate > backlog on unstable releases. That means that GUB needs to get switched > over to Python 3. For those following along: It's not that we need to convert GUB to Python 3, just switch the dependencies of the LilyPond spec. > It may make it more prudent, should we need to > release 2.20.1 at some time, to also go to the cherry-picking nightmare > required to bring stable/2.20 up to Python 3. My point of view remains: Just keep an old version of GUB around and we're fine for 2.20.x, x > 0. Jonas signature.asc Description: This is a digitally signed message part
Re: 2.20 and 2.21 release plans
Jonas Hahnfeld writes: > Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup: >> Ok, I think 2.20 is basically done and we should push it out by the end >> of this week. This leaves a few days for the translation team to catch >> up with the current state. > > Wohoo! > >> [...] >> >> What does this mean for 2.21.0? I think we should aim to push it out >> fast afterwards, basically a few days later at most, just to get kinks >> with webpage/versioning from 2.20 ironed out. >> >> [...] >> >> For more extensive changes of internals and/or syntax, I would recommend >> to let them sit till 2.21.1 before committing, assuming that we _do_ >> manage to get 2.21.0 out fast. Why? 2.21.0 has by now quite >> significantly diverged from 2.20.0. If something does not quite work, >> it would be nice to have a _released_ version to compare to, and nothing >> but 2.21.0 would really serve that role satisfactorily. Particularly >> where problems are detected a long time after getting introduced, having >> an installable version as a reference is nice, and "it stopped working >> in 2.21.0" is enough of a quagmire already that we do not really want to >> add a lot more here. > > Sounds good (well, Python 3 is already in). To be sure: This also means > we'll be using GUB for 2.21.0? I'd like to propose a new system (yes, > *with* support for Windows) soon, but not sure that I can make it in > the next week or so... Yes, GUB for 2.21.0. We don't want to have another indeterminate backlog on unstable releases. That means that GUB needs to get switched over to Python 3. It may make it more prudent, should we need to release 2.20.1 at some time, to also go to the cherry-picking nightmare required to bring stable/2.20 up to Python 3. Definitely a holdup I would not have wanted for 2.20.0. If we want to switch over to a different release method, we can do that comfortably without unstable releases being blocked. Whether we want to eventually bring out a 2.20 version in that manner too (which might bring different platform support) or save it for 2.22 or whenever is something I don't think we should try pinning down now. >> The size of the headache basically is commensurate with how long the >> stable branch has diverged. Hopefully we manage to find some >> combination of process and responsible persons next time around that >> delivers faster. > > To throw this idea onto the mailing list: Time-based releases seem to > encourage a predictable schedule. I don't think it makes sense to have > monthly stable releases as, for example, GitLab does. But maybe > tracking something like once in a year to 18 months with defined > windows for alpha and beta releases? We have to see how this pans out. The last release cycle saw something like a half-year blockage due to GUB problems. It's not like anybody wanted this to keep up for as long as it did. And there is no point in committing to schedules if there are no persons tied into the commitment. It's not like I didn't offer the release manager job for grabs several times round with no takers. Committing to regular schedules with me as sole release manager candidate is a predictable setup for disappointment. -- David Kastrup
Re: 2.20 and 2.21 release plans
Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup: > Ok, I think 2.20 is basically done and we should push it out by the end > of this week. This leaves a few days for the translation team to catch > up with the current state. Wohoo! > [...] > > What does this mean for 2.21.0? I think we should aim to push it out > fast afterwards, basically a few days later at most, just to get kinks > with webpage/versioning from 2.20 ironed out. > > [...] > > For more extensive changes of internals and/or syntax, I would recommend > to let them sit till 2.21.1 before committing, assuming that we _do_ > manage to get 2.21.0 out fast. Why? 2.21.0 has by now quite > significantly diverged from 2.20.0. If something does not quite work, > it would be nice to have a _released_ version to compare to, and nothing > but 2.21.0 would really serve that role satisfactorily. Particularly > where problems are detected a long time after getting introduced, having > an installable version as a reference is nice, and "it stopped working > in 2.21.0" is enough of a quagmire already that we do not really want to > add a lot more here. Sounds good (well, Python 3 is already in). To be sure: This also means we'll be using GUB for 2.21.0? I'd like to propose a new system (yes, *with* support for Windows) soon, but not sure that I can make it in the next week or so... > The size of the headache basically is commensurate with how long the > stable branch has diverged. Hopefully we manage to find some > combination of process and responsible persons next time around that > delivers faster. To throw this idea onto the mailing list: Time-based releases seem to encourage a predictable schedule. I don't think it makes sense to have monthly stable releases as, for example, GitLab does. But maybe tracking something like once in a year to 18 months with defined windows for alpha and beta releases? Jonas signature.asc Description: This is a digitally signed message part
2.20 and 2.21 release plans
Ok, I think 2.20 is basically done and we should push it out by the end of this week. This leaves a few days for the translation team to catch up with the current state. In particular HINT HINT HINT it gives the opportunity to native speakers of languages not as meticulously maintained as the currently most active translations to at least tackle the Changes document and maybe check a few other points of the web presence. This is more addressed to people reading this announcement on the lilypond-devel list than to lurkers on the translations list, though of course the latter would be equally welcome. What does this mean for 2.21.0? I think we should aim to push it out fast afterwards, basically a few days later at most, just to get kinks with webpage/versioning from 2.20 ironed out. I am not sure it is realistic to expect to get the translations merged into 2.21.0 already: because of the significant divergence experienced so far, I expect this to be a significant merging headache. It would be nice to have, but not essential: this is the unstable branch after all. For more extensive changes of internals and/or syntax, I would recommend to let them sit till 2.21.1 before committing, assuming that we _do_ manage to get 2.21.0 out fast. Why? 2.21.0 has by now quite significantly diverged from 2.20.0. If something does not quite work, it would be nice to have a _released_ version to compare to, and nothing but 2.21.0 would really serve that role satisfactorily. Particularly where problems are detected a long time after getting introduced, having an installable version as a reference is nice, and "it stopped working in 2.21.0" is enough of a quagmire already that we do not really want to add a lot more here. The size of the headache basically is commensurate with how long the stable branch has diverged. Hopefully we manage to find some combination of process and responsible persons next time around that delivers faster. Nevertheless, I am glad we are getting there. -- David Kastrup
