Re: Remove lily-git?
Le 04/06/2020 à 19:47, Jean Abou Samra a écrit : Based on the replies, I created https://gitlab.com/lilypond/lilypond/-/merge_requests/123 That was the wrong link. Here you go: https://gitlab.com/lilypond/lilypond/-/merge_requests/125
Re: new procedure with GitLab CI
Le 01/06/2020 à 22:39, Jean Abou Samra a écrit : David Kastrup wrote: So I lean towards the following process modeled upon our old one: No push to master except by automation. Staging is unprotected and gets scheduled runners. People ultimately rebase and push there once they get Patch-push status. Default branch can be master as long as we make sure that one cannot push there: that way you never rebase on ephemeral commits. When James gives Patch-push status (which he hopefully does supported by a script), at the same time any merge request pointed at master gets changed to point at staging. So if you are "Patch-push", the "Push" button starts working. That means as long as staging isn't stuck (and we should make sure that the scheduled pipelines do not pick up the same commit more than once to avoid wasting our minutes), you can rebase on master when you want (or not). One initial pipeline run should be require to get into "Review" state. Rebasing puts you back to "Patch-new" (which for trivial stuff you may choose to hand-replace with "Patch-review" at the danger of later getting staging borked). It would be nice that if staging has tested as being borked, we could temporarily disable pushes to staging: that will keep the patches and merge requests requiring redoing limited. We got out along without that previously but if the automation is good for that, that would be great. At any rate, this scheme naively does not seem to require stuff impossible to do with Gitlab, at least for the basic parts of operation. And it would mean that you can usually rebase and forget without waiting for pipeline completions. And you get the liberty of bypassing most CI and rebases if you don't want to. I may be wrong about the possibility to do this with a reasonable amount of effort: I don't want to get hopes up unnecessarily. That sounds reasonable, but alas, rather complicated. What about the other option, that is, switching to a non-linear history, with merge commits? My fear is that we get back to a complex and non-standard development process. The simple fact of having two branches to look at is already a source of confusion for the unexperimented (for instance, merge requests will target master at the time you create them, but that will change for staging automatically). From the information I could gather, one of the main incentives for moving to GitLab was making it easier to contribute by standardizing the workflow. GitLab does everything we want, the only blocker is the fast-forward merge strategy, if I understand well (please correct me in case I don't). I would happily live with merge commits if that facilitates development for everyone. Plus, a non-linear history would skip all the rebases, which are creating unnecessary noise within the merge requests. And it would be a lot less work to set up, given that Jonas expressed to be fed-up. Actually, I had anticipated a long thread full of reactionson bothof the above options, but not such a silence. Anyone? (I won't feel offended if you find my proposal dumb!) Regards, Jean Abou Samra PS: Perhaps I understand (?): And, I very much understand the difficulties you're facing in real life, the nerve-wracking French lockdown, the thorny situation artists face, etc. So if LilyPond is an additional cause of frustration for you, maybe it could do you good to set it aside for a while and focus on your current problems. At least, that's what I did. I thereby didn't mean that I myself was frustrated by LilyPond but that I myself had set LilyPond aside for a while because I had other issues to deal with.
Re: Remove lily-git?
Hi, Thank you all for your input. Le 04/06/2020 à 13:54, Urs Liska a écrit : Am Donnerstag, den 04.06.2020, 13:36 +0200 schrieb Jean Abou Samra: I do agree with you that Git can be a bit of a trick to learn (at least, there is a long path before you fully master it). What if right now we just added a link to some Git graphical client like https://www.syntevo.com/smartgit/? SmartGit is a great Git client, but it is proprietary, so we can't link to it (even provided they have a free (lowercase 'f') license for non- commercial work). Unfortunately I haven't yet found a Free GUI tool that made me feel comfortable, so I've always got back to it. Damned! You're right. Then let's not link to anything at all (yet). It doesn't remove the complexity of Git (obviously that's quite more involved than lily-git, the target not being the same), but at the very least, you don't need to bother with a command-line interface. lily-git is not going to be usable in an immediate future. Anyway, if I had to write something, I would do it in Python as per the abovementioned issue (now that recent versions of Python ship with tkinter). And as we're still trying to figure out how exactly we are going to work with GitLab, starting a new tool right now doesn't look like a good idea. So, what I would propose at this point is to drop lily-git.tcl, as it doesn't provide a value neither for a user these days, nor for the people that could develop a new tool in Python in the future; then, depending on how things go on, and if we feel the need for it, write lily-git.py or whatever. Maybe we could open an issue to track that. Makes sense? To me, yes. But I don't think that is too relevant here. Best Urs Based on the replies, I created https://gitlab.com/lilypond/lilypond/-/merge_requests/123 (pipelines failed, I still need to investigate), and https://gitlab.com/lilypond/lilypond/-/issues/5997 Regards, Jean Abou Samra
Re: Remove lily-git?
Am Donnerstag, den 04.06.2020, 13:36 +0200 schrieb Jean Abou Samra: > Hi, > Le 04/06/2020 à 08:31, James Lowe a écrit : > > On 03/06/2020 21:25, Karlin High wrote: > > > On 6/3/2020 3:14 PM, Jean Abou Samra wrote: > > > > There is a discussion at > > > > https://gitlab.com/lilypond/lilypond/-/issues/1012 > > > > about the future of lily-git.Basically, I think that it no > > > > longer > > > > makes sense to keep it now that we switched to GitLab. > > > > > > I remember seeing this thing bring in over 500MB of dependencies > > > on a > > > Debian Linux system. And I was thinking, "If that's the only > > > piece of > > > TCL in the whole LilyPond ecosystem, there has GOT to be a way > > > to > > > avoid having this." > > > > I am not sure that is correct, lily-git is just a set of python > > commands with a Front End GUI (for the likes of me) that made sure > > that you had set your git repo correctly and could easily download > > $LILYPOND_GIT. It also forced you to set your git user and email. > > > > Lily-git in and of itself was tiny and needed hardly anything to > > run > > (wish lily-git.tcl). > > > > The 500MB of dependencies was, I expect, for dblatex et al. That > > we > > needed for doc building at the time but lily-git only cloned the > > repo > > (and allowed a button to hard reset - again for idiots like me). > > > > I am a bit older and wiser now, but even so git is still a > > terrible > > 'ecosystem' not made much better by the gitlabs and githubs of the > > world (I have the joy of having to interface with both as a > > non-developer). That said, yes we don't 'need' lily-git, however > > I'd > > like to give a hat-tip to the few devs that kept it going so I > > could > > do my work. If it weren't for lily-git (and at the start 'lily-dev' > > - > > still less faff than containers and jails BTW for non-devs) I'd > > have > > not been able to easily contribute to this project and may have > > simply > > given up having to learn the terrible interface that is git cli > > with > > all the breakages of master we had at the start of when I joined. > > > > James > I do agree with you that Git can be a bit of a trick to learn (at > least, > there is a long path before you fully master it). What if right now > we > just added a link to some Git graphical client like > https://www.syntevo.com/smartgit/? SmartGit is a great Git client, but it is proprietary, so we can't link to it (even provided they have a free (lowercase 'f') license for non- commercial work). Unfortunately I haven't yet found a Free GUI tool that made me feel comfortable, so I've always got back to it. > It doesn't remove the complexity of Git (obviously that's quite more > involved than lily-git, the target not being the same), but at the > very > least, you don't need to bother with a command-line interface. > > lily-git is not going to be usable in an immediate future. > Anyway, if I had to write something, I would do it in Python as per > the abovementioned issue (now that recent versions of Python ship > with tkinter). And as we're still trying to figure out how exactly > we are going to work with GitLab, starting a new tool right now > doesn't look like a good idea. So, what I would propose at this point > is > to drop lily-git.tcl, as it doesn't provide a value neither for a > user > these days, nor for the people that could develop a new tool in > Python > in the future; then, depending on how things go on, and if we feel > the > need for it, write lily-git.py or whatever. Maybe we could open an > issue > to track that. Makes sense? To me, yes. But I don't think that is too relevant here. Best Urs > > Best, > Jean Abou Samra > >
Re: Remove lily-git?
Hi, Le 04/06/2020 à 08:31, James Lowe a écrit : On 03/06/2020 21:25, Karlin High wrote: On 6/3/2020 3:14 PM, Jean Abou Samra wrote: There is a discussion at https://gitlab.com/lilypond/lilypond/-/issues/1012 about the future of lily-git.Basically, I think that it no longer makes sense to keep it now that we switched to GitLab. I remember seeing this thing bring in over 500MB of dependencies on a Debian Linux system. And I was thinking, "If that's the only piece of TCL in the whole LilyPond ecosystem, there has GOT to be a way to avoid having this." I am not sure that is correct, lily-git is just a set of python commands with a Front End GUI (for the likes of me) that made sure that you had set your git repo correctly and could easily download $LILYPOND_GIT. It also forced you to set your git user and email. Lily-git in and of itself was tiny and needed hardly anything to run (wish lily-git.tcl). The 500MB of dependencies was, I expect, for dblatex et al. That we needed for doc building at the time but lily-git only cloned the repo (and allowed a button to hard reset - again for idiots like me). I am a bit older and wiser now, but even so git is still a terrible 'ecosystem' not made much better by the gitlabs and githubs of the world (I have the joy of having to interface with both as a non-developer). That said, yes we don't 'need' lily-git, however I'd like to give a hat-tip to the few devs that kept it going so I could do my work. If it weren't for lily-git (and at the start 'lily-dev' - still less faff than containers and jails BTW for non-devs) I'd have not been able to easily contribute to this project and may have simply given up having to learn the terrible interface that is git cli with all the breakages of master we had at the start of when I joined. James I do agree with you that Git can be a bit of a trick to learn (at least, there is a long path before you fully master it). What if right now we just added a link to some Git graphical client like https://www.syntevo.com/smartgit/? It doesn't remove the complexity of Git (obviously that's quite more involved than lily-git, the target not being the same), but at the very least, you don't need to bother with a command-line interface. lily-git is not going to be usable in an immediate future. Anyway, if I had to write something, I would do it in Python as per the abovementioned issue (now that recent versions of Python ship with tkinter). And as we're still trying to figure out how exactly we are going to work with GitLab, starting a new tool right now doesn't look like a good idea. So, what I would propose at this point is to drop lily-git.tcl, as it doesn't provide a value neither for a user these days, nor for the people that could develop a new tool in Python in the future; then, depending on how things go on, and if we feel the need for it, write lily-git.py or whatever. Maybe we could open an issue to track that. Makes sense? Best, Jean Abou Samra
PATCHES - Countdown for June 4th
Hello, Here is the current patch countdown list. The next countdown will be on June 6th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !115 Declare music iterator classes "final" when applicable - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/115 !114 compute_foo → calc_foo - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/114 !113 Set GS page size in device properties - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/113 !112 Resolve "Fix mixups of Drul_array and Interval_t" - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/112 !111 Copy the device when using the Ghostscript API - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/111 !109 Update syntax & behavior for fingerings & string numbers - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/109 !106 Inline musicxml make templates - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/106 !104 misc cleanups in lilypond-book - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/104 !98 fix rounded corner skylines - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/98 !91 Doc: expand NR 1.6.2.3 Hiding staves - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/91 !72 Move skylines_from_stencil out of the Stencil class - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/72 !56 Break substitution cleanup - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/56 Countdown: !80 Resolve "fingeringOrientations don't deal properly with omitted Fingering-stencils" - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/80 Review: !122 Music_iterator: derive `ok` from `pending_moment` and `run_always` - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/122 !94 Support C++ range-for iteration of SCM lists - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/94 New: !123 WIP: Update Contributor Guide for GitLab - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/123 !120 Doc: document new ottavation properties - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/120 !119 Allow lyric hyphens to be repeated after system breaks - David Stephen Grant https://gitlab.com/lilypond/lilypond/-/merge_requests/119 !117 unify logic for CLI and API access to GS - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/117 Waiting: !96 Doc: add TMPDIR in Usage (fix #5993) - Federico Bruni https://gitlab.com/lilypond/lilypond/-/merge_requests/96 *** Regards, James
Re: Remove lily-git?
On 03/06/2020 21:25, Karlin High wrote: On 6/3/2020 3:14 PM, Jean Abou Samra wrote: There is a discussion at https://gitlab.com/lilypond/lilypond/-/issues/1012 about the future of lily-git.Basically, I think that it no longer makes sense to keep it now that we switched to GitLab. I remember seeing this thing bring in over 500MB of dependencies on a Debian Linux system. And I was thinking, "If that's the only piece of TCL in the whole LilyPond ecosystem, there has GOT to be a way to avoid having this." I am not sure that is correct, lily-git is just a set of python commands with a Front End GUI (for the likes of me) that made sure that you had set your git repo correctly and could easily download $LILYPOND_GIT. It also forced you to set your git user and email. Lily-git in and of itself was tiny and needed hardly anything to run (wish lily-git.tcl). The 500MB of dependencies was, I expect, for dblatex et al. That we needed for doc building at the time but lily-git only cloned the repo (and allowed a button to hard reset - again for idiots like me). I am a bit older and wiser now, but even so git is still a terrible 'ecosystem' not made much better by the gitlabs and githubs of the world (I have the joy of having to interface with both as a non-developer). That said, yes we don't 'need' lily-git, however I'd like to give a hat-tip to the few devs that kept it going so I could do my work. If it weren't for lily-git (and at the start 'lily-dev' - still less faff than containers and jails BTW for non-devs) I'd have not been able to easily contribute to this project and may have simply given up having to learn the terrible interface that is git cli with all the breakages of master we had at the start of when I joined. James
