Re: Verifying issues on Gitlab
Hey, we're down to 520! BTW, instead of scrolling to the bottom of the comments to find the commit id, it's easier to set the sorting of the comments to "newest first", which puts the commit ID very near the top. Maybe I can get us under 500 before I go to bed tonight. Carl On 5/11/20, 4:29 PM, "lilypond-devel on behalf of Federico Bruni" wrote: Il giorno lun 11 mag 2020 alle 17:12, Karlin High ha scritto: > On 5/11/2020 5:01 PM, Federico Bruni wrote: >> If nobody else jumps in, I will probably give up soon. > > If someone wants to help, are there step-by-step directions anywhere? > Start from this list: https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=closed_name[]=Fixed_2_21_0_name[]=Status%3A%3AFixed In the last comment you should find a commit id (if it's missing you'll have to search it). The easiest and quickest way to verify that a certain id has been included in the release tag label used in the issue is using Github. Start from this URL: https://github.com/lilypond/lilypond/commit/ then append the commit id you want to verify, e.g.: https://github.com/lilypond/lilypond/commit/bed9afff763d274af3a2608bdbbc61c807653dbd At the beginning you'll see the branches and the tags where this commit is present. The oldest release tag is the one which should be used as label in the Gitlab issue. If everything seems Ok to you, just change the status to Verified. Click on Edit in the Labels section and as you start typing status, Gitlab will list the possible entries and you can select Verified, which will replace Accepted. More details (out-of-date) here: http://lilypond.org/doc/v2.21/Documentation/contributor/the-bug-squad
Re: GitLab repo breaks make website?
On May 11, 2020, at 19:42, Caio Barros wrote: > > Then I noticed that on the "old" repo there was GNUmakefile.in > and GNUmakefile. The second one is not present on the "new" repo, so i did ... > > Am I missing something? Run autogen.sh and/or configure? — Dan
GitLab repo breaks make website?
Hello! When I cloned the GitLab repo to my LilyDev container I couldn't build the website anymore. I tried: $ make website make: *** No rule to make target 'website'. Stop. Then I noticed that on the "old" repo there was GNUmakefile.in and GNUmakefile. The second one is not present on the "new" repo, so i did $ cp ../lilypond-git-old/GNUmakefile ./ but then I got $ make website make/stepmake.make:23: config.make: No such file or directory make/toplevel-version.make:6: /VERSION: No such file or directory make/stepmake.make:115: /stepmake/generic-vars.make: No such file or directory make/stepmake.make:115: /stepmake/toplevel-vars.make: No such file or directory make/stepmake.make:115: /stepmake/po-vars.make: No such file or directory make/stepmake.make:115: /stepmake/install-vars.make: No such file or directory make: /python/langdefs.py: Command not found make: /python/langdefs.py: Command not found make/substitute.make:4: /stepmake/substitute-vars.make: No such file or directory make/substitute.make:5: /stepmake/substitute-rules.make: No such file or directory make/stepmake.make:122: /stepmake/generic-rules.make: No such file or directory make/stepmake.make:122: /stepmake/toplevel-rules.make: No such file or directory make/stepmake.make:122: /stepmake/po-rules.make: No such file or directory make/stepmake.make:122: /stepmake/install-rules.make: No such file or directory make/stepmake.make:124: /stepmake/generic-targets.make: No such file or directory make/stepmake.make:124: /stepmake/toplevel-targets.make: No such file or directory make/stepmake.make:124: /stepmake/po-targets.make: No such file or directory make/stepmake.make:124: /stepmake/install-targets.make: No such file or directory make: *** No rule to make target '/stepmake/install-targets.make'. Stop. Am I missing something? Caio
Re: Verifying issues on Gitlab
Em seg., 11 de mai. de 2020 às 19:29, Federico Bruni escreveu: > Start from this list: > > https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=closed_name[]=Fixed_2_21_0_name[]=Status%3A%3AFixed > > In the last comment you should find a commit id (if it's missing you'll > have to search it). > The easiest and quickest way to verify that a certain id has been > included in the release tag label used in the issue is using Github. > Start from this URL: > > https://github.com/lilypond/lilypond/commit/ > > then append the commit id you want to verify, e.g.: > > > https://github.com/lilypond/lilypond/commit/bed9afff763d274af3a2608bdbbc61c807653dbd > > At the beginning you'll see the branches and the tags where this commit > is present. > The oldest release tag is the one which should be used as label in the > Gitlab issue. > > If everything seems Ok to you, just change the status to Verified. > Click on Edit in the Labels section and as you start typing status, > Gitlab will list the possible entries and you can select Verified, > which will replace Accepted. > > More details (out-of-date) here: > http://lilypond.org/doc/v2.21/Documentation/contributor/the-bug-squad If it's ok with you I can help as well but I think I don't have permission to edit the labels. Anyway, thanks for the steps. Caio
Re: Verifying issues on Gitlab
Federico, Thanks for the clear instructions. I'll start jumping in, but it will probably be on the order of about 10 per day, give or take. I think we can get this under control eventually Thanks, Carl
Re: Verifying issues on Gitlab
Federico, you wrote 11/05/2020 23:01:14 I've started verifying issues on Gitlab. It's quite straightforward, but still boring :-) I think that most of the times it's "useless", meaning that I can't find any error.. but sometimes you may find something useful to report: a new command to be documented, an unclear new feature, etc. The problem is that the number of issues to be verified, only for 2.21.0, is still huge (552): https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=closed_name[]=Fixed_2_21_0_name[]=Status%3A%3AFixed and only 21 issues have been verified so far: https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=closed_name[]=Fixed_2_21_0_name[]=Status%3A%3AVerified If nobody else jumps in, I will probably give up soon. I've verified a few this evening, and will keep plugging away slowly from time to time ... at least for a while. Trevor
Re: Verifying issues on Gitlab
Il giorno lun 11 mag 2020 alle 17:12, Karlin High ha scritto: On 5/11/2020 5:01 PM, Federico Bruni wrote: If nobody else jumps in, I will probably give up soon. If someone wants to help, are there step-by-step directions anywhere? Start from this list: https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=closed_name[]=Fixed_2_21_0_name[]=Status%3A%3AFixed In the last comment you should find a commit id (if it's missing you'll have to search it). The easiest and quickest way to verify that a certain id has been included in the release tag label used in the issue is using Github. Start from this URL: https://github.com/lilypond/lilypond/commit/ then append the commit id you want to verify, e.g.: https://github.com/lilypond/lilypond/commit/bed9afff763d274af3a2608bdbbc61c807653dbd At the beginning you'll see the branches and the tags where this commit is present. The oldest release tag is the one which should be used as label in the Gitlab issue. If everything seems Ok to you, just change the status to Verified. Click on Edit in the Labels section and as you start typing status, Gitlab will list the possible entries and you can select Verified, which will replace Accepted. More details (out-of-date) here: http://lilypond.org/doc/v2.21/Documentation/contributor/the-bug-squad
Re: Verifying issues on Gitlab
On 5/11/2020 5:01 PM, Federico Bruni wrote: If nobody else jumps in, I will probably give up soon. If someone wants to help, are there step-by-step directions anywhere? -- Karlin High Missouri, USA
Re: Verifying issues on Gitlab
Federico Bruni writes: > Hi all > > I've started verifying issues on Gitlab. > It's quite straightforward, but still boring :-) > I think that most of the times it's "useless", meaning that I can't > find any error.. but sometimes you may find something useful to > report: a new command to be documented, an unclear new feature, etc. > > The problem is that the number of issues to be verified, only for > 2.21.0, is still huge (552): > https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=closed_name[]=Fixed_2_21_0_name[]=Status%3A%3AFixed > > and only 21 issues have been verified so far: > https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=closed_name[]=Fixed_2_21_0_name[]=Status%3A%3AVerified > > If nobody else jumps in, I will probably give up soon. The verification was more about checking that a particular commit made it into a particular version if I remember correctly. "A new command to be documented, an unclear new feature, etc..." is above the pay grade of the Bug Squad basically asked to do the verification (I know, I know: I've not exactly been great at keeping our infrastructure workers recruited and dedicated). -- David Kastrup
Verifying issues on Gitlab
Hi all I've started verifying issues on Gitlab. It's quite straightforward, but still boring :-) I think that most of the times it's "useless", meaning that I can't find any error.. but sometimes you may find something useful to report: a new command to be documented, an unclear new feature, etc. The problem is that the number of issues to be verified, only for 2.21.0, is still huge (552): https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=closed_name[]=Fixed_2_21_0_name[]=Status%3A%3AFixed and only 21 issues have been verified so far: https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=closed_name[]=Fixed_2_21_0_name[]=Status%3A%3AVerified If nobody else jumps in, I will probably give up soon.
PATCHES - Countdown for May 11th
Hello, Here is the current patch countdown list. The next countdown will be on May 13th. **IMPORTANT PLEASE READ*** Patches now need to have a merge request for them to get on the countdown list - as this is the first countdown for the changeover, and because not all the patches in the queue have merge requests since the migration on Sunday, I have had to make the list manually from the old sourceforge/Rietveld comments and the new Gitlab script Jonas kindly did for me. Any patches that were on 'Countdown' or 'Review' have been 'moved along' (i.e. the label changed and the appropriate comment in the issue) but please create a merge request if requested so that it appears properly on the next countdown. For those 'new' patches that had not had merge requests or patches that were on review/countdown but then had new patches created in Rietveld, can you make a merge request so that it appears on the 'lists' for testing? It will probably not be on the list below for this countdown (I will check again tomorrow to pick up any missed testing). Sorry in advance for any mistakes below while I work with Jonas to make sure that I can efficiently find the issues with patches and their relevant state in the countdown. If you don't see your patch in the list below it is probably my fault or it needs a merge request (did I mention that?!). Thanks, hopefully by the next countdown it will be much clearer for us all. *** Push: No patches in Push at this time. Countdown: Prevent race condition in `-dfont-ps-resdir` - Masamichi Hosoda [1]https://gitlab.com/lilypond/lilypond/-/issues/5968 Stop smobifying Transform - Han-Wen Nienhuys [2]https://gitlab.com/lilypond/lilypond/-/issues/5966 Make Scheme_hash_table just use the native hash table type. This - David Kastrup [3]https://gitlab.com/lilypond/lilypond/-/issues/5965 dynamics on skips confuse cross-staff stems - barrykp [4]https://gitlab.com/lilypond/lilypond/-/issues/4182 Review: No patches in Review at this time. New: !5 Enable 'relative-includes by default. - Valentin Villenave [5]https://gitlab.com/lilypond/lilypond/-/merge_requests/5 !4 Ensure having valid references to the position in the source file while... - Martin Neubauer [6]https://gitlab.com/lilypond/lilypond/-/merge_requests/4 !3 Add dynamic-interface to keepAliveInterfaces - Jean Abou Samra [7]https://gitlab.com/lilypond/lilypond/-/merge_requests/3 !2 Issue 5965 - Make Scheme_hash_table just use the native hash table type. - David Kastrup [8]https://gitlab.com/lilypond/lilypond/-/merge_requests/2 !1 web: Update links from SourceForge to GitLab - Jonas Hahnfeld [9]https://gitlab.com/lilypond/lilypond/-/merge_requests/1 Waiting: No patches in Waiting at this time. *** Regards, James References Visible links 1. https://sourceforge.net/p/testlilyissues/issues/5968 2. https://sourceforge.net/p/testlilyissues/issues/5966 3. https://sourceforge.net/p/testlilyissues/issues/5965 4. https://sourceforge.net/p/testlilyissues/issues/4182 5. https://gitlab.com/lilypond/lilypond/-/merge_requests/5 6. https://gitlab.com/lilypond/lilypond/-/merge_requests/4 7. https://gitlab.com/lilypond/lilypond/-/merge_requests/3 8. https://gitlab.com/lilypond/lilypond/-/merge_requests/2 9. https://gitlab.com/lilypond/lilypond/-/merge_requests/1 Hidden links: 11. http://codereview.appspot.com/567580043 12. http://codereview.appspot.com/561810043 13. http://codereview.appspot.com/554030043 14. http://codereview.appspot.com/561810043
Re: Compiling from LilyDev
Hi Jaap, Thank you for helping me find the issue! I double checked, and I didn't miss any of those steps. I figured I must have messed something up earlier on, maybe in the VirtualBox configuration, and sure enough, when I made a fresh dynamic image and did everything over again, the ../configure step worked perfectly. At any rate, I can now continue with compiling, so I'll let you know if I encounter any more issues. --Owen On Sun, May 10, 2020 at 9:34 PM wrote: > > > -Oorspronkelijk bericht- > > Van: lilypond-devel de-wolff@gnu.org> > > Namens Carl Sorensen > > Verzonden: Monday, May 11, 2020 5:43 AM > > Aan: Owen Lamb ; Werner LEMBERG ; > > lilypond-devel@gnu.org; Federico Bruni > > Onderwerp: Re: Compiling from LilyDev > > > > > > On 5/10/20, 8:50 PM, "lilypond-devel on behalf of Owen Lamb" > devel-bounces+c_sorensen=byu@gnu.org on behalf of > > owendl...@gmail.com> wrote: > > > > Hi all, > > > > I've hit a couple roadblocks trying to compile LilyPond from LilyDev as > per the > > instructions on the website( > > http://lilypond.org/doc/v2.21/Documentation/contributor/compiling-with- > > lilydev), > > both during the "Preparing the build" step where ../configure is run. > > > > First, the environment variable $METAFONT wasn't defined, making the > > Checking for metafont mode... step fail. I set it to the value I thought > it would > > need, the executable at /usr/bin/mf. That seemed to fix the issue, but I > just > > wanted to make sure--the variable *is *supposed to point there, right? > > > > Second, I'm getting an error on three other steps, all referring to a > missing > > kpsewhich file or folder: > > > > checking for metapost required files... lstat(./kpsewhich) failed ... > > ./kpsewhich: No such file or directory > > kpsewhich: ../../../texk/kpathsea/progname.c:316: remove_dots: Assertion > > `ret' failed. > > no > > [...] > > checking for epsf.tex... lstat(./kpsewhich) failed ... > > ./kpsewhich: No such file or directory > > kpsewhich: ../../../texk/kpathsea/progname.c:316: remove_dots: Assertion > > `ret' failed. > > not found > > checking for Cyrillic characters support in TeX... lstat(./kpsewhich) > failed ... > > ./kpsewhich: No such file or directory > > kpsewhich: ../../../texk/kpathsea/progname.c:316: remove_dots: Assertion > > `ret' failed. > > not found > > > > This causes an error later on: > > ERROR: Please install required programs: metapost CTAN package > > (texlive-metapost) epsf.tex lh CTAN package (texlive-lang-cyrillic or > > texlive-texmf-fonts) > > ...even though they are installed. > > > > I don't really know what kpeswitch is supposed to do, so... does anyone > know > > what went wrong? > > > > -- > > Response from Carl Sorensen: > > > > Owen, > > > > Great job working through all this! Getting LilyPond compiling can be a > bear. > > LilyDev used to work completely out-of-the-box, but it seems like as > we've > > tried to make it a smaller install, it's not so foolproof. > > > > Kpsewhich is part of the TeX system -- it's a utility that searches the > kpathsea > > paths to find files. But I don't know how to fix the problem in your > copy of > > LilyDev. > > > > Federico Bruni is probably the most knowledgeable person on LilyDev. > I've > > added him to the responses on this email. > > > > Sorry I'm not more help. > > > > Carl > > > > Carl, > > I just created a new machine from the LilyDev image. > I created a Hyper-V machine instead of a virtual box image, but for the > matter of your problem that should not be a problem. > I can run ../configure without a problem, and did run make. > > So the LilyDev image is correct. > > I have no environment variable $METAFONT, so that is not needed. > > Just to be sure you did not forget a major step: > Did you run ~/install.sh? > (http://lilypond.org/doc/v2.21/Documentation/contributor/lilydev > installing lilydev point 14 > Did you run autogen.sh --noconfigure while in the $LILYPOND_GIT folder? > Did you run ../configure while in the $LILYPOND_GIT folder? > Is the value of $LILYPOND_GIT (echo $LILYPOND_GIT) lilypond-git? > (This is set so in ~/setup.sh) > > One more point: During setup.sh you need a stable internet connection. > I hope this all helps you > > Jaap de Wolff > >
Re: SourceForge still open
Hi, Jonas, you wrote 11/05/2020 10:21:21 Apparently I failed to disable write access to SourceForge. Please do not use it, new issues and comments will not be mirrored to GitLab! (If somebody is able to help: Yesterday I dropped all groups the permission to "create" and "update". I've now also removed the individual tool permissions for "Issues", but I'm still able to post comments. Maybe that's because I have admin permissions, I don't know.) Most likely, yes. I just did the test and was unable to post new comments. However, I do have the permission to modify comments that I previously wrote. That's of little importance though. Best, Jean Abou Samra
Re: repository at GitLab
Am Montag, den 11.05.2020, 15:00 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Montag, den 11.05.2020, 14:54 +0200 schrieb David Kastrup: > > > Jonas Hahnfeld writes: > > > > Yes, I think pushing existing reviews as a merge request is the easiest > > > > solution. For the beginning we could of course also live with a mixture > > > > of (old-style) issues and merge requests, but the countdown script I > > > > wrote for James only considers merge requests. So pushing as a branch > > > > and adding the previous label to the MR would be great. > > > > > > > > For merging I would not use the UI yet but manually push to staging as > > > > before. So targeting 'master' by default for now shouldn't be a > > > > problem. > > > > > > It turns out that issues have above the discussion a menu entry to open > > > a merge request. I have not found an obvious way to link a merge > > > request created independently to an issue. > > > > This will create a branch starting with issue number, no big magic > > though. > > > > > So instead of pushing independently as a merge request (unless the merge > > > request is of the common form of stating and solving a problem or task > > > at the same time), it seems to be the right way to open the merge > > > request in the existing issue and go from there. > > > > > > I'll try doing that in parallel now, and possibly decide to kill the > > > independent merge request if that works. > > > > Instead you may put a "Closes #" into the last of your commits. > > This will automatically link the MR and even close the issue once the > > commits hit master. > > It would appear that the merge request now is listed as "linked" in the > issue, possibly because of a comment I posted referencing it. > > Issue numbers are recognised with # syntax in general? Yes, here's the full list of references: https://docs.gitlab.com/ee/user/markdown.html#special-gitlab-references For us, issues (#) and MRs (!) are likely the most important. Jonas signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Jonas Hahnfeld writes: > Am Montag, den 11.05.2020, 14:54 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Yes, I think pushing existing reviews as a merge request is the easiest >> > solution. For the beginning we could of course also live with a mixture >> > of (old-style) issues and merge requests, but the countdown script I >> > wrote for James only considers merge requests. So pushing as a branch >> > and adding the previous label to the MR would be great. >> > >> > For merging I would not use the UI yet but manually push to staging as >> > before. So targeting 'master' by default for now shouldn't be a >> > problem. >> >> It turns out that issues have above the discussion a menu entry to open >> a merge request. I have not found an obvious way to link a merge >> request created independently to an issue. > > This will create a branch starting with issue number, no big magic > though. > >> So instead of pushing independently as a merge request (unless the merge >> request is of the common form of stating and solving a problem or task >> at the same time), it seems to be the right way to open the merge >> request in the existing issue and go from there. >> >> I'll try doing that in parallel now, and possibly decide to kill the >> independent merge request if that works. > > Instead you may put a "Closes #" into the last of your commits. > This will automatically link the MR and even close the issue once the > commits hit master. It would appear that the merge request now is listed as "linked" in the issue, possibly because of a comment I posted referencing it. Issue numbers are recognised with # syntax in general? -- David Kastrup
Re: repository at GitLab
Am Montag, den 11.05.2020, 14:54 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Yes, I think pushing existing reviews as a merge request is the easiest > > solution. For the beginning we could of course also live with a mixture > > of (old-style) issues and merge requests, but the countdown script I > > wrote for James only considers merge requests. So pushing as a branch > > and adding the previous label to the MR would be great. > > > > For merging I would not use the UI yet but manually push to staging as > > before. So targeting 'master' by default for now shouldn't be a > > problem. > > It turns out that issues have above the discussion a menu entry to open > a merge request. I have not found an obvious way to link a merge > request created independently to an issue. This will create a branch starting with issue number, no big magic though. > So instead of pushing independently as a merge request (unless the merge > request is of the common form of stating and solving a problem or task > at the same time), it seems to be the right way to open the merge > request in the existing issue and go from there. > > I'll try doing that in parallel now, and possibly decide to kill the > independent merge request if that works. Instead you may put a "Closes #" into the last of your commits. This will automatically link the MR and even close the issue once the commits hit master. Jonas signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Jonas Hahnfeld writes: > Am Montag, den 11.05.2020, 14:22 +0200 schrieb David Kastrup: >> David Kastrup writes: >> > Jonas Hahnfeld writes: >> > > Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup: >> > > > dak@lola:/usr/local/tmp/lilypond$ git push -o merge_request.create >> > > > -o merge_request.target=staging -o merge_request.title="Issue 5965" >> > > > origin issue5965:issue5965 >> > > >> > > Interesting, didn't know about this possibility... >> > >> > The funny thing is I don't know about any other possibility. Web >> > interfaces are not really my thing, and this is what I found when >> > grasping around. > > Just push any new branch to the repository or a fork and you'll be > presented with a link on the command line. Alternatively GitLab > remembers your last push and shows a corresponding button somewhere at > the top. > >> > I now try figuring out where my merge request ends up >> > and how it can be found and treated from the web interface. > > It's now here: https://gitlab.com/lilypond/lilypond/-/merge_requests/2 > >> > It probably should be a project-wide setting to have >> > merge_request.target=staging as default? > > Merge requests are opened against the default branch, which is set to > 'master' right now. I can of course switch to 'staging', but that would > also mean a fresh clone starts at 'staging' which is probably not what > we want. > >> > > Just added you (and all others that were in lilypond-trial) to the >> > > lilypond group. >> > >> > Thanks. >> >> And actually, I don't know what the workflow right now is and whether I >> even was supposed to push something to the central repo to get it (back) >> under review. This was basically just me prodding the repo for lack of >> any other idea of how to interact. I know now how to do one thing. I >> just don't know whether this is what I am supposed to be doing. > > Yes, I think pushing existing reviews as a merge request is the easiest > solution. For the beginning we could of course also live with a mixture > of (old-style) issues and merge requests, but the countdown script I > wrote for James only considers merge requests. So pushing as a branch > and adding the previous label to the MR would be great. > > For merging I would not use the UI yet but manually push to staging as > before. So targeting 'master' by default for now shouldn't be a > problem. It turns out that issues have above the discussion a menu entry to open a merge request. I have not found an obvious way to link a merge request created independently to an issue. So instead of pushing independently as a merge request (unless the merge request is of the common form of stating and solving a problem or task at the same time), it seems to be the right way to open the merge request in the existing issue and go from there. I'll try doing that in parallel now, and possibly decide to kill the independent merge request if that works. -- David Kastrup
Re: repository at GitLab
Am Montag, den 11.05.2020, 14:22 +0200 schrieb David Kastrup: > David Kastrup writes: > > Jonas Hahnfeld writes: > > > Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup: > > > > dak@lola:/usr/local/tmp/lilypond$ git push -o merge_request.create > > > > -o merge_request.target=staging -o merge_request.title="Issue 5965" > > > > origin issue5965:issue5965 > > > > > > Interesting, didn't know about this possibility... > > > > The funny thing is I don't know about any other possibility. Web > > interfaces are not really my thing, and this is what I found when > > grasping around. Just push any new branch to the repository or a fork and you'll be presented with a link on the command line. Alternatively GitLab remembers your last push and shows a corresponding button somewhere at the top. > > I now try figuring out where my merge request ends up > > and how it can be found and treated from the web interface. It's now here: https://gitlab.com/lilypond/lilypond/-/merge_requests/2 > > It probably should be a project-wide setting to have > > merge_request.target=staging as default? Merge requests are opened against the default branch, which is set to 'master' right now. I can of course switch to 'staging', but that would also mean a fresh clone starts at 'staging' which is probably not what we want. > > > Just added you (and all others that were in lilypond-trial) to the > > > lilypond group. > > > > Thanks. > > And actually, I don't know what the workflow right now is and whether I > even was supposed to push something to the central repo to get it (back) > under review. This was basically just me prodding the repo for lack of > any other idea of how to interact. I know now how to do one thing. I > just don't know whether this is what I am supposed to be doing. Yes, I think pushing existing reviews as a merge request is the easiest solution. For the beginning we could of course also live with a mixture of (old-style) issues and merge requests, but the countdown script I wrote for James only considers merge requests. So pushing as a branch and adding the previous label to the MR would be great. For merging I would not use the UI yet but manually push to staging as before. So targeting 'master' by default for now shouldn't be a problem. Jonas signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
David Kastrup writes: > Jonas Hahnfeld writes: > >> Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup: >>> Jonas Hahnfeld writes: >>> > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup: >>> > > Jonas Hahnfeld < >>> > > hah...@hahnjo.de >>> > > > writes: >>> > > > Everything went pretty much as expected, so here's the repo: >>> > > > >>> > > > https://gitlab.com/lilypond/lilypond >>> > > > >>> > > > If you already have a local repository cloned from Savannah, execute >>> > > > $ git remote set-url origin >>> > > > g...@gitlab.com >>> > > > :lilypond/lilypond.git >>> > > > to switch to GitLab (or edit your .git/config manually if preferred). >>> > > >>> > > Wouldn't that just be readonly access? >>> > >>> > It has updated both for me, probably because I used SSH for both fetch >>> > and push. >>> >>> dak@lola:/usr/local/tmp/lilypond$ git push -o merge_request.create >>> -o merge_request.target=staging -o merge_request.title="Issue 5965" >>> origin issue5965:issue5965 >> >> Interesting, didn't know about this possibility... > > The funny thing is I don't know about any other possibility. Web > interfaces are not really my thing, and this is what I found when > grasping around. I now try figuring out where my merge request ends up > and how it can be found and treated from the web interface. > > It probably should be a project-wide setting to have > merge_request.target=staging as default? > >> Just added you (and all others that were in lilypond-trial) to the >> lilypond group. > > Thanks. And actually, I don't know what the workflow right now is and whether I even was supposed to push something to the central repo to get it (back) under review. This was basically just me prodding the repo for lack of any other idea of how to interact. I know now how to do one thing. I just don't know whether this is what I am supposed to be doing. -- David Kastrup
Re: repository at GitLab
Jonas Hahnfeld writes: > Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup: >> > > Jonas Hahnfeld < >> > > hah...@hahnjo.de >> > > > writes: >> > > > Everything went pretty much as expected, so here's the repo: >> > > > >> > > > https://gitlab.com/lilypond/lilypond >> > > > >> > > > If you already have a local repository cloned from Savannah, execute >> > > > $ git remote set-url origin >> > > > g...@gitlab.com >> > > > :lilypond/lilypond.git >> > > > to switch to GitLab (or edit your .git/config manually if preferred). >> > > >> > > Wouldn't that just be readonly access? >> > >> > It has updated both for me, probably because I used SSH for both fetch >> > and push. >> >> dak@lola:/usr/local/tmp/lilypond$ git push -o merge_request.create >> -o merge_request.target=staging -o merge_request.title="Issue 5965" >> origin issue5965:issue5965 > > Interesting, didn't know about this possibility... The funny thing is I don't know about any other possibility. Web interfaces are not really my thing, and this is what I found when grasping around. I now try figuring out where my merge request ends up and how it can be found and treated from the web interface. It probably should be a project-wide setting to have merge_request.target=staging as default? > Just added you (and all others that were in lilypond-trial) to the > lilypond group. Thanks. -- David Kastrup
Re: repository at GitLab
Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup: > > > Jonas Hahnfeld < > > > hah...@hahnjo.de > > > > writes: > > > > Everything went pretty much as expected, so here's the repo: > > > > > > > > https://gitlab.com/lilypond/lilypond > > > > > > > > If you already have a local repository cloned from Savannah, execute > > > > $ git remote set-url origin > > > > g...@gitlab.com > > > > :lilypond/lilypond.git > > > > to switch to GitLab (or edit your .git/config manually if preferred). > > > > > > Wouldn't that just be readonly access? > > > > It has updated both for me, probably because I used SSH for both fetch > > and push. > > dak@lola:/usr/local/tmp/lilypond$ git push -o merge_request.create -o > merge_request.target=staging -o merge_request.title="Issue 5965" origin > issue5965:issue5965 Interesting, didn't know about this possibility... > remote: > remote: > > remote: > remote: You are not allowed to push code to this project. > remote: > remote: > > remote: > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. Just added you (and all others that were in lilypond-trial) to the lilypond group. Jonas signature.asc Description: This is a digitally signed message part
Re: SourceForge still open
Jonas, you wrote 11/05/2020 10:21:21 Apparently I failed to disable write access to SourceForge. Please do not use it, new issues and comments will not be mirrored to GitLab! (If somebody is able to help: Yesterday I dropped all groups the permission to "create" and "update". I've now also removed the individual tool permissions for "Issues", but I'm still able to post comments. Maybe that's because I have admin permissions, I don't know.) AFAICS you did everything necessary and correctly. I can't see what else might be needed. There is a comment that changes might take a few minutes to propagate, but it's already been several hours. :( Trevor
Re: repository at GitLab
Jonas Hahnfeld writes: > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Everything went pretty much as expected, so here's the repo: >> > https://gitlab.com/lilypond/lilypond >> > If you already have a local repository cloned from Savannah, execute >> > $ git remote set-url origin >> > g...@gitlab.com:lilypond/lilypond.git >> > to switch to GitLab (or edit your .git/config manually if preferred). >> >> Wouldn't that just be readonly access? > > It has updated both for me, probably because I used SSH for both fetch > and push. dak@lola:/usr/local/tmp/lilypond$ git push -o merge_request.create -o merge_request.target=staging -o merge_request.title="Issue 5965" origin issue5965:issue5965 remote: remote: remote: remote: You are not allowed to push code to this project. remote: remote: remote: fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. -- David Kastrup
Re: repository at GitLab
>> Please give me access too; my username on GitLab is 'lemzwerg'. > > Done. Thanks! Werner
Re: repository at GitLab
Jonas Hahnfeld writes: > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Everything went pretty much as expected, so here's the repo: >> > https://gitlab.com/lilypond/lilypond >> > If you already have a local repository cloned from Savannah, execute >> > $ git remote set-url origin >> > g...@gitlab.com:lilypond/lilypond.git >> > to switch to GitLab (or edit your .git/config manually if preferred). >> >> Wouldn't that just be readonly access? > > It has updated both for me, probably because I used SSH for both fetch > and push. Ah, ok. I think I misread git:gitlab.com for g...@gitlab.com here. -- David Kastrup
Re: repository at GitLab
Am Montag, den 11.05.2020, 11:52 +0200 schrieb Jonas Hahnfeld: > Am Montag, den 11.05.2020, 11:39 +0200 schrieb Werner LEMBERG: > > > I granted everybody access to the group > > > https://gitlab.com/lilypond who > > > sent requests so far. > > > > Please give me access too; my username on GitLab is 'lemzwerg'. > > Done. > > > Another question is what to do with the lilypond git mirror on > > github... > > If we want to keep the mirror, we can make GitLab push updates > automatically as potentially discussed for Savannah. Sorry if I'm asking things I might have read if I had been able to pay closer attention recently. With the repository on Gitlab.com anybody who has an account can freely fork the repository and interact with that fork. (And from there then create Pull Requests to interact with the official repository.) If that's the case I don't think there's an actual need for a mirror on Github anymore. The original intention to set this up has been to enable people to work with the code without having to ask for permissions on the Savannah repository. My suggestion would be to disable that mirror by updating the README.md and archiving it (i.e. making it read-only). Urs > > Jonas
Re: repository at GitLab
Am Montag, den 11.05.2020, 11:39 +0200 schrieb Werner LEMBERG: > > I granted everybody access to the group https://gitlab.com/lilypond who > > sent requests so far. > > Please give me access too; my username on GitLab is 'lemzwerg'. Done. > Another question is what to do with the lilypond git mirror on > github... If we want to keep the mirror, we can make GitLab push updates automatically as potentially discussed for Savannah. Jonas signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Everything went pretty much as expected, so here's the repo: > > https://gitlab.com/lilypond/lilypond > > If you already have a local repository cloned from Savannah, execute > > $ git remote set-url origin > > g...@gitlab.com:lilypond/lilypond.git > > to switch to GitLab (or edit your .git/config manually if preferred). > > Wouldn't that just be readonly access? It has updated both for me, probably because I used SSH for both fetch and push. signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Jonas Hahnfeld writes: > Everything went pretty much as expected, so here's the repo: > https://gitlab.com/lilypond/lilypond > If you already have a local repository cloned from Savannah, execute > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > to switch to GitLab (or edit your .git/config manually if preferred). Wouldn't that just be readonly access? -- David Kastrup
Re: repository at GitLab
> Everything went pretty much as expected, so here's the repo: > https://gitlab.com/lilypond/lilypond Congrats, and thank you very much for your hard work! > I granted everybody access to the group https://gitlab.com/lilypond who > sent requests so far. Please give me access too; my username on GitLab is 'lemzwerg'. Another question is what to do with the lilypond git mirror on github... Werner
SourceForge still open
Apparently I failed to disable write access to SourceForge. Please do not use it, new issues and comments will not be mirrored to GitLab! (If somebody is able to help: Yesterday I dropped all groups the permission to "create" and "update". I've now also removed the individual tool permissions for "Issues", but I'm still able to post comments. Maybe that's because I have admin permissions, I don't know.) signature.asc Description: This is a digitally signed message part
repository at GitLab
Everything went pretty much as expected, so here's the repo: https://gitlab.com/lilypond/lilypond If you already have a local repository cloned from Savannah, execute $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git to switch to GitLab (or edit your .git/config manually if preferred). I granted everybody access to the group https://gitlab.com/lilypond who sent requests so far. Please make sure that your username is recognizable to match with something that had access to SourceForge / Savannah. If in doubt just send me a private email because there's no possibility to reply to incoming access request from within GitLab. The general process stays in place, please push to staging instead of directly to master. Whoever runs patchy, please update the configuration as described above. To open a merge request, there are two possibilities: either fork the project or push a new dev/* branch directly to the repo and follow the links. The label Patch::new should be added automatically. If you want to get emails for the project: GitLab has a notification setting per project (little bell to the right of the project name). "Watch" will notify you about everything (new issues, merge requests, comments, ...), otherwise you can tick what you want with "Custom". So much for now. I expect us to figure things out as we go, and most probably change some if suitable. Jonas signature.asc Description: This is a digitally signed message part
