Re: somebody needs to run staging before 29 Jan
2012/1/29 David Kastrup d...@gnu.org: So seriously: this needs to move to a different computer if LilyPond development is of concern to you all. My work on Patchy (to make it more foolproof and more operator-friendly, i.e. 'run-a-script-and-everything-gets-done-automatically') will unfortunately take some more time; it's harder than i thought and i have to focus on my exams again. I estimate to finish it until 5 Feb - Graham, it would be great if you decided to run Patchy yourself a week longer. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Janek Warchoł janek.lilyp...@gmail.com writes: 2012/1/29 David Kastrup d...@gnu.org: So seriously: this needs to move to a different computer if LilyPond development is of concern to you all. My work on Patchy (to make it more foolproof and more operator-friendly, i.e. 'run-a-script-and-everything-gets-done-automatically') will unfortunately take some more time; it's harder than i thought and i have to focus on my exams again. I estimate to finish it until 5 Feb - Graham, it would be great if you decided to run Patchy yourself a week longer. The test-patches.py script can likely make use of the techniques in lilypond-patchy-staging.ly with regard to doing an offside build with a defined starting point not relying on whatever happens to be checked out in the main repository. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 12:37:58PM +0100, Janek Warchoł wrote: 2012/1/29 David Kastrup d...@gnu.org: So seriously: this needs to move to a different computer if LilyPond development is of concern to you all. My work on Patchy (to make it more foolproof and more operator-friendly, i.e. 'run-a-script-and-everything-gets-done-automatically') ... that's ALREADY how it works for the staging-merge. will unfortunately take some more time; it's harder than i thought and i have to focus on my exams again. I estimate to finish it until 5 Feb - Graham, it would be great if you decided to run Patchy yourself a week longer. I refuse. Jan 29 was the deadline; that deadline has passed. I will not be running the staging-merge. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 12:47:11PM +0100, David Kastrup wrote: The test-patches.py script can likely make use of the techniques in lilypond-patchy-staging.ly with regard to doing an offside build with a defined starting point not relying on whatever happens to be checked out in the main repository. Don't get confused here. Don't scare people away from doing the staging-merge by talking about test-patches.py. test-patches.py is a completely different problem than the staging merge. I agree that a solution for test-patches.py should be found, but that's not as urgent, nor as TRIVIALLY easy to fix, as the fact that you are the only person running the staging-merge at the moment. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Graham Percival gra...@percival-music.ca writes: On Mon, Jan 30, 2012 at 12:47:11PM +0100, David Kastrup wrote: The test-patches.py script can likely make use of the techniques in lilypond-patchy-staging.ly with regard to doing an offside build with a defined starting point not relying on whatever happens to be checked out in the main repository. Don't get confused here. Don't scare people away from doing the staging-merge by talking about test-patches.py. test-patches.py is a completely different problem than the staging merge. I agree that a solution for test-patches.py should be found, but that's not as urgent, nor as TRIVIALLY easy to fix, as the fact that you are the only person running the staging-merge at the moment. I am not sure what the problem is with anybody else running it. You call it, and it complains about LILYPOND_GIT not being set. Then you call LILYPOND_GIT=/usr/local/tmp/lilypond /usr/local/tmp/lilypond-extra/patches/lilypond-patchy-staging.py (assuming that your full repository copy is in /usr/local/tmp/lilypond) and it complains that the configuration in ~/.lilypond-patchy-config is wrong. You call a text editor and insert directories and paths suitable to your system in that file, and that is about it. There is not much to make this easier or better discoverable short of adding a complete configuration program that will write the respective data. I have to admit to not even reading the CG here. I just ran the script that had a title suggesting it would do the right thing, and it apparently did after I addressed its rather clear complaints. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 12:59:57PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: Don't get confused here. Don't scare people away from doing the staging-merge by talking about test-patches.py. I am not sure what the problem is with anybody else running it. ditto, other than the sheer it's something I haven't done before factor. Don't underestimate that: unix people have no problem running an unknown program and skimming the man page if necessary, but other people are reluctant to do this. You call it, and it complains about LILYPOND_GIT not being set. That's covered in the beginning of the CG now, and it's built-in to lilydev 2.0. (assuming that your full repository copy is in /usr/local/tmp/lilypond) and it complains that the configuration in ~/.lilypond-patchy-config is wrong. Yep. You call a text editor and insert directories and paths suitable to your system in that file, and that is about it. Yep. There is not much to make this easier or better discoverable short of adding a complete configuration program that will write the respective data. Yep. I have to admit to not even reading the CG here. Admittedly, none of the above is in the CG (other than the LILYPOND_GIT environment variable stuff). But really, it's just as you say: the instructions are pretty clear. I just ran the script that had a title suggesting it would do the right thing, and it apparently did after I addressed its rather clear complaints. Great! Hopefully somebody will see these emails and realize there's nothing to fear. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
- Original Message - From: Graham Percival gra...@percival-music.ca To: David Kastrup d...@gnu.org Cc: lilypond-devel@gnu.org Sent: Monday, January 30, 2012 12:08 PM Subject: Re: somebody needs to run staging before 29 Jan On Mon, Jan 30, 2012 at 12:59:57PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: Don't get confused here. Don't scare people away from doing the staging-merge by talking about test-patches.py. I am not sure what the problem is with anybody else running it. ditto, other than the sheer it's something I haven't done before factor. Don't underestimate that: unix people have no problem running an unknown program and skimming the man page if necessary, but other people are reluctant to do this. You call it, and it complains about LILYPOND_GIT not being set. That's covered in the beginning of the CG now, and it's built-in to lilydev 2.0. (assuming that your full repository copy is in /usr/local/tmp/lilypond) and it complains that the configuration in ~/.lilypond-patchy-config is wrong. Yep. You call a text editor and insert directories and paths suitable to your system in that file, and that is about it. Yep. There is not much to make this easier or better discoverable short of adding a complete configuration program that will write the respective data. Yep. I have to admit to not even reading the CG here. Admittedly, none of the above is in the CG (other than the LILYPOND_GIT environment variable stuff). But really, it's just as you say: the instructions are pretty clear. I just ran the script that had a title suggesting it would do the right thing, and it apparently did after I addressed its rather clear complaints. Great! Hopefully somebody will see these emails and realize there's nothing to fear. - Graham I'll have a look later. But. I assume it uses the normal git cache on my computer - is there any danger if this is also my dev machine with other changed files in the git filesystem (e.g. the LSR copies, for example). My brief look at one of the scripts showed an expectation of using a RAMdisk. I'd rather use my SSD. Does this involve any changes? Please confirm which script should be the main master and what to look for when it's running. smtp_command: msmtp -C ~/.msmtp-patchy -t means nothing to me. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Phil Holmes m...@philholmes.net writes: I assume it uses the normal git cache on my computer Nope. It uses whatever repository you specify in the LILYPOND_GIT environment variable. - is there any danger if this is also my dev machine with other changed files in the git filesystem (e.g. the LSR copies, for example). Depends on what you specify in LILYPOND_GIT and the configuration file. My brief look at one of the scripts showed an expectation of using a RAMdisk. I'd rather use my SSD. Does this involve any changes? Configuration of the respective paths. Please confirm which script should be the main master and what to look for when it's running. I don't quite understand what you are asking here, but presumably you mean lilypond-extra/patches/lilypond-patchy-staging.py or so. smtp_command: msmtp -C ~/.msmtp-patchy -t means nothing to me. That is command for mailing the completion message somewhere. I have no idea what msmtp is supposed to be, but I replaced it with mail dak on my system. Which is not really what was intended, I guess, because it mailed a mail to me addressed to Graham and the developer list. msmtp would likely have bypassed me doing that. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On 2012-01-30 12:59, David Kastrup wrote: Graham Percivalgra...@percival-music.ca writes: On Mon, Jan 30, 2012 at 12:47:11PM +0100, David Kastrup wrote: The test-patches.py script can likely make use of the techniques in lilypond-patchy-staging.ly with regard to doing an offside build with a defined starting point not relying on whatever happens to be checked out in the main repository. Don't get confused here. Don't scare people away from doing the staging-merge by talking about test-patches.py. test-patches.py is a completely different problem than the staging merge. I agree that a solution for test-patches.py should be found, but that's not as urgent, nor as TRIVIALLY easy to fix, as the fact that you are the only person running the staging-merge at the moment. I am not sure what the problem is with anybody else running it. You call it, and it complains about LILYPOND_GIT not being set. Then you call LILYPOND_GIT=/usr/local/tmp/lilypond /usr/local/tmp/lilypond-extra/patches/lilypond-patchy-staging.py (assuming that your full repository copy is in /usr/local/tmp/lilypond) and it complains that the configuration in ~/.lilypond-patchy-config is wrong. You call a text editor and insert directories and paths suitable to your system in that file, and that is about it. I can run it regularly (i.e. a cron job) on my office machine (recently got a really fast quad-core system), which is up 24/7 and doesn't have too much load otherwise. I don't know how much time I'll have to set it up, though. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Monday, January 30, 2012 1:07 PM Subject: Re: somebody needs to run staging before 29 Jan Phil Holmes m...@philholmes.net writes: I assume it uses the normal git cache on my computer Nope. It uses whatever repository you specify in the LILYPOND_GIT environment variable. But if I rely on other uses for the LILYPOND_GIT environment variable, then it must use my normal git stash. Strikes me it would be safer to have a duplicate stash just for patchy, and a different variable. - is there any danger if this is also my dev machine with other changed files in the git filesystem (e.g. the LSR copies, for example). Depends on what you specify in LILYPOND_GIT and the configuration file. My brief look at one of the scripts showed an expectation of using a RAMdisk. I'd rather use my SSD. Does this involve any changes? Configuration of the respective paths. In the scripts or in a config file? Please confirm which script should be the main master and what to look for when it's running. I don't quite understand what you are asking here, but presumably you mean lilypond-extra/patches/lilypond-patchy-staging.py or so. I think that's what I meant. smtp_command: msmtp -C ~/.msmtp-patchy -t means nothing to me. That is command for mailing the completion message somewhere. I have no idea what msmtp is supposed to be, but I replaced it with mail dak on my system. Which is not really what was intended, I guess, because it mailed a mail to me addressed to Graham and the developer list. msmtp would likely have bypassed me doing that. I don't have a mail account on that machine, so would need to configure it to use my normal SMTP provider, but don't know how to do that. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 02:07:44PM +0100, David Kastrup wrote: Phil Holmes m...@philholmes.net writes: smtp_command: msmtp -C ~/.msmtp-patchy -t means nothing to me. That is command for mailing the completion message somewhere. I have no idea what msmtp is supposed to be, ah yes, I forgot about that. It's a replacement of smtp, specifically aimed at mutt users, but the mutt part is irrelevant. on my system. Which is not really what was intended, I guess, because it mailed a mail to me addressed to Graham and the developer list. msmtp would likely have bypassed me doing that. err, yeah; I guess that part should be configurable, so staging-merge isn't completely finished. But at a pinch, one could just leave the smtp_command: blank, and then it won't do any mailing at all. I mean, that's sufficient to have the merge happening. For relevance, I have this: lily@gperciva-desktop:~$ more .msmtp-patchy account gmail host smtp.gmail.com port 587 auth on user lilypond.patchy.gra...@gmail.com password hunter2 tls on tls_trust_file /usr/share/ca-certificates/mozilla/Equifax_Secure_CA.crt from lilypond.patchy.gra...@gmail.com account default: gmail ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 01:35:24PM -, Phil Holmes wrote: Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Monday, January 30, 2012 1:07 PM Subject: Re: somebody needs to run staging before 29 Jan Nope. It uses whatever repository you specify in the LILYPOND_GIT environment variable. But if I rely on other uses for the LILYPOND_GIT environment variable, then it must use my normal git stash. Strikes me it would be safer to have a duplicate stash just for patchy, and a different variable. Yes, I have patchy on a completely separate user. Configuration of the respective paths. In the scripts or in a config file? config file. smtp_command: msmtp -C ~/.msmtp-patchy -t means nothing to me. on my system. Which is not really what was intended, I guess, because it mailed a mail to me addressed to Graham and the developer list. msmtp would likely have bypassed me doing that. I don't have a mail account on that machine, so would need to configure it to use my normal SMTP provider, but don't know how to do that. I happened to send instructions for this about 60 seconds ago. :) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Phil Holmes m...@philholmes.net writes: Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Monday, January 30, 2012 1:07 PM Subject: Re: somebody needs to run staging before 29 Jan Phil Holmes m...@philholmes.net writes: I assume it uses the normal git cache on my computer Nope. It uses whatever repository you specify in the LILYPOND_GIT environment variable. But if I rely on other uses for the LILYPOND_GIT environment variable, then it must use my normal git stash. Strikes me it would be safer to have a duplicate stash just for patchy, and a different variable. I have had my fingers on the respective code in the past. It uses the repository as a read-only resource, with the exception of a) running git fetch to get up-to-date branches b) creating and deleting branches called something like test-staging (so that you can reference later which staging was actually being tested) and something like test-master-lock which is both used as a lock to stop parallel instances of patchy to run, as well as a reference to the master at the start of the test run. Those separate branches are created right after running git fetch and are later used for pushing the results upstream if the results are ok. So no, there is little point in not using your main git stash for this. Apart from it being more up-to-date in its remote branches than you remember, and from two mysterious branches coming and going, it will not be affected. Most particularly your work directory and your checkouts are not being touched. This is for the staging patchy; the Rietveld patchy is a different beast yet. In the scripts or in a config file? config file as well as LILYPOND_GIT environment variable. The scripts themselves do not appear to need changes. That is command for mailing the completion message somewhere. I have no idea what msmtp is supposed to be, but I replaced it with mail dak on my system. Which is not really what was intended, I guess, because it mailed a mail to me addressed to Graham and the developer list. msmtp would likely have bypassed me doing that. I don't have a mail account on that machine, so would need to configure it to use my normal SMTP provider, but don't know how to do that. I presume any old command taking standard input should to. Something like cat /tmp/patchy-completion-mails or so should likely work. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
[Applying rietveld 5595043 to git afb4c5fb] It means running your own files that use this feature, and reading the docs to see whether the docs as well as the new incarnation of the feature make sense to you. It was really good that you have been a pain in the neck, since your patch causes rhythmic problems. [...] My piece looks fine now, thanks! Triplets are OK. No time to check your documentation, though. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Werner LEMBERG w...@gnu.org writes: [Applying rietveld 5595043 to git afb4c5fb] It means running your own files that use this feature, and reading the docs to see whether the docs as well as the new incarnation of the feature make sense to you. It was really good that you have been a pain in the neck, since your patch causes rhythmic problems. [...] My piece looks fine now, thanks! Triplets are OK. No time to check your documentation, though. Let me just quote one item by screenshot inline: Screenshot at 2012-01-30 15:35:55.png and suggest looking at input/regression/tablature-chord-repetition-finger.ly as this may save you some time afterwards. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org; David Kastrup d...@gnu.org Sent: Monday, January 30, 2012 1:40 PM Subject: Re: somebody needs to run staging before 29 Jan On Mon, Jan 30, 2012 at 01:35:24PM -, Phil Holmes wrote: Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Monday, January 30, 2012 1:07 PM Subject: Re: somebody needs to run staging before 29 Jan Nope. It uses whatever repository you specify in the LILYPOND_GIT environment variable. But if I rely on other uses for the LILYPOND_GIT environment variable, then it must use my normal git stash. Strikes me it would be safer to have a duplicate stash just for patchy, and a different variable. Yes, I have patchy on a completely separate user. OK - just set one up and trying a test build. My other current concern is to wonder whether lots of people trying to get patchy running might not collide with each other. As I understand it, the key patchy function is to pull patches from staging, run make and make test, and check the regtest output. If this is OK it sends a message saying LGTM. Is this correct? Does it actually do any of the merging of patches from staging into master? I wouldn't want to do that without knowing I was doing it... (although my new user would presumably fail anyway, since I've not yet set it up for push access). -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Phil Holmes m...@philholmes.net writes: My other current concern is to wonder whether lots of people trying to get patchy running might not collide with each other. As I understand it, the key patchy function is to pull patches from staging, The current state of staging. It does not test individually. run make and make test, and check the regtest output. If this is OK it sends a message saying LGTM. Is this correct? Nope, it bounces master to staging (or recommends doing it, depending on what Graham did). Does it actually do any of the merging of patches from staging into master? I wouldn't want to do that without knowing I was doing it... (although my new user would presumably fail anyway, since I've not yet set it up for push access). It tries doing so. If parallel users try that, it will succeed for every one of them unless someone is trying to push something older than something that already got pushed. Or if his version of staging has been, in the mean time, replaced by something else that has been pushed instead. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 04:39:31PM +0100, David Kastrup wrote: Phil Holmes m...@philholmes.net writes: My other current concern is to wonder whether lots of people trying to get patchy running might not collide with each other. I don't think so; once the first set of commits were pushed to master, I would expect that other people will just get a non-fast-forwarding reply when Patchy attempts to push to master. As I understand it, the key patchy function is to pull patches from staging, The current state of staging. It does not test individually. run make and make test, and check the regtest output. No regtest examination. It builds make, make test, and make doc, and if nothing fails -- using the make(1) definition of fails -- then it merges and pushes to master. If this is OK it sends a message saying LGTM. Is this correct? Nope, it bounces master to staging (or recommends doing it, depending on what Graham did). It bounces master to staging directly. It sends a personal mail saying it's done; if it fails, it sends a personal mail CC'd to -devel. But the mail can be dispensed with for the first few tests. Does it actually do any of the merging of patches from staging into master? I wouldn't want to do that without knowing I was doing it... (although my new user would presumably fail anyway, since I've not yet set it up for push access). Yes, but the whole point is that you don't need to know what you're doing. The script handles it (as long as your new user has git push access). - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Let me just quote one item by screenshot [...] This looks excellent. However, I don't understand the last sentence. What do you mean with `not transferred'? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Werner LEMBERG w...@gnu.org writes: Let me just quote one item by screenshot [...] This looks excellent. However, I don't understand the last sentence. What do you mean with `not transferred'? I reworded the text and changed the example. It should now be clearer from both text and picture. inline: Screenshot at 2012-01-30 17:40:37.png -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
2012/1/30 Graham Percival gra...@percival-music.ca: On Mon, Jan 30, 2012 at 12:37:58PM +0100, Janek Warchoł wrote: 2012/1/29 David Kastrup d...@gnu.org: So seriously: this needs to move to a different computer if LilyPond development is of concern to you all. My work on Patchy (to make it more foolproof and more operator-friendly, i.e. 'run-a-script-and-everything-gets-done-automatically') that's ALREADY how it works for the staging-merge. I guess i mean something different than you do when i say everything gets done automatically. will unfortunately take some more time; it's harder than i thought and i have to focus on my exams again. I estimate to finish it until 5 Feb - Graham, it would be great if you decided to run Patchy yourself a week longer. I refuse. Jan 29 was the deadline; that deadline has passed. I will not be running the staging-merge. As you wish, but please note that this gets me very unmotivated to do anything and continue my work. Following your plea for more automation, and knowing about problems with Patchy that showed on 2240, i decided to pause my other Lily work and focus on improving Patchy and our development workflow. I took the approach of solving problem causes instead of symptoms: it takes more time, but its better in the long run. I've spent about 30 hours on Patchy in the previous week despite exam season. Now i feel like a noob because i haven't finished a simple python script till Jan 29, and my 30 hours of work seem to be worthless. Great. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: Graham Percival gra...@percival-music.ca Cc: David Kastrup d...@gnu.org; lilypond-devel@gnu.org Sent: Monday, January 30, 2012 5:56 PM Subject: Re: somebody needs to run staging before 29 Jan 2012/1/30 Graham Percival gra...@percival-music.ca: On Mon, Jan 30, 2012 at 12:37:58PM +0100, Janek Warchoł wrote: 2012/1/29 David Kastrup d...@gnu.org: So seriously: this needs to move to a different computer if LilyPond development is of concern to you all. My work on Patchy (to make it more foolproof and more operator-friendly, i.e. 'run-a-script-and-everything-gets-done-automatically') that's ALREADY how it works for the staging-merge. I guess i mean something different than you do when i say everything gets done automatically. will unfortunately take some more time; it's harder than i thought and i have to focus on my exams again. I estimate to finish it until 5 Feb - Graham, it would be great if you decided to run Patchy yourself a week longer. I refuse. Jan 29 was the deadline; that deadline has passed. I will not be running the staging-merge. As you wish, but please note that this gets me very unmotivated to do anything and continue my work. Following your plea for more automation, and knowing about problems with Patchy that showed on 2240, i decided to pause my other Lily work and focus on improving Patchy and our development workflow. I took the approach of solving problem causes instead of symptoms: it takes more time, but its better in the long run. I've spent about 30 hours on Patchy in the previous week despite exam season. Now i feel like a noob because i haven't finished a simple python script till Jan 29, and my 30 hours of work seem to be worthless. Great. Janek Keep going. I hope to have the current version working soon, and we then need to improve and document it. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
I reworded the text and changed the example. It should now be clearer from both text and picture. Yes, thanks. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Mon, Jan 30, 2012 at 06:56:08PM +0100, Janek Warchoł wrote: 2012/1/30 Graham Percival gra...@percival-music.ca: that's ALREADY how it works for the staging-merge. I guess i mean something different than you do when i say everything gets done automatically. I think there's confusion between Patchy staging-merge and Patchy test-patches. They share the Patchy name because 90% of the code is the same, but the staging-merge is a much easier, and much better-tested, task. I refuse. Jan 29 was the deadline; that deadline has passed. I will not be running the staging-merge. As you wish, but please note that this gets me very unmotivated to do anything and continue my work. Following your plea for more automation, and knowing about problems with Patchy that showed on 2240, That's a problem with test-patches, not staging-merge. i decided to pause my other Lily work and focus on improving Patchy and our development workflow. I took the approach of solving problem causes instead of symptoms: it takes more time, but its better in the long run. Yes, and that's valuable for the future. I've spent about 30 hours on Patchy in the previous week despite exam season. Now i feel like a noob because i haven't finished a simple python script till Jan 29, and my 30 hours of work seem to be worthless. Great. I think you were working on the wrong problem -- a problem which *will* be important in the future. I haven't yet set a date for when I refuse to run test-patches yet, but I'm thinking about Feb 14. Why am I doing this? Because yelling about our bus factor and the problems of not automating things has not resulted in enough attention. If you doubt my yelling, check the email archives. I am very serious about potentially leaving for good at the end of March. That would leave a lot of maintenance tasks not getting done. And if I officially leave lilypond and somebody asks for help doing some maintenance task, I may not bother to reply. I make no guarantees. The time to panic about not knowing how to do those tasks is NOW, while I'm still available to give some guidance. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
2012/1/30 Graham Percival gra...@percival-music.ca: I think there's confusion between Patchy staging-merge and Patchy test-patches. I don't feel confused at all, don't worry about it. i decided to pause my other Lily work and focus on improving Patchy and our development workflow. I took the approach of solving problem causes instead of symptoms: it takes more time, but its better in the long run. Yes, and that's valuable for the future. Had you added a thank you, you'd have made me happy. (just stating a fact) I've spent about 30 hours on Patchy in the previous week despite exam season. Now i feel like a noob because i haven't finished a simple python script till Jan 29, and my 30 hours of work seem to be worthless. Great. I think you were working on the wrong problem -- a problem which *will* be important in the future. I haven't yet set a date for when I refuse to run test-patches yet, but I'm thinking about Feb 14. since 90% of the code is shared, it doesn't make much sense to me to work on one part of Patchy at a time. The time to panic about not knowing how to do those tasks is NOW, I assure that i'm panicking the most i can. A!, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
James pkx1...@gmail.com writes: --snip-- james@jameslilydev2:~/Desktop/patchy$ ./run-lilypond-staging.sh remote: Counting objects: 83, done. remote: Compressing objects: 100% (57/57), done. remote: Total 57 (delta 45), reused 0 (delta 0) Unpacking objects: 100% (57/57), done. From ssh://git.sv.gnu.org/srv/git/lilypond 39f5057..5a61803 master - origin/master ad3a9e6..8019ff7 staging- origin/staging From ssh://git.sv.gnu.org/srv/git/lilypond * [new tag] release/2.15.27-1 - release/2.15.27-1 Branch test-master-lock set up to track remote branch master from origin. Branch test-staging set up to track remote branch staging from origin. Initialized empty Git repository in /home/james/Desktop/patchy/lilypond-autobuild/.git/ fatal: attempt to fetch/clone from a shallow repository fatal: The remote end hung up unexpectedly Begin LilyPond compile, commit: 39f50579ff91fdca06acd52a9392ab2874f4723b and I don't know where I need to look from here. Run git fetch --depth=100 in your original repository. That should convert it from a shallow repository to a full one. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
David, On 29 January 2012 08:48, David Kastrup d...@gnu.org wrote: James pkx1...@gmail.com writes: --snip-- james@jameslilydev2:~/Desktop/patchy$ ./run-lilypond-staging.sh remote: Counting objects: 83, done. remote: Compressing objects: 100% (57/57), done. remote: Total 57 (delta 45), reused 0 (delta 0) Unpacking objects: 100% (57/57), done. From ssh://git.sv.gnu.org/srv/git/lilypond 39f5057..5a61803 master - origin/master ad3a9e6..8019ff7 staging - origin/staging From ssh://git.sv.gnu.org/srv/git/lilypond * [new tag] release/2.15.27-1 - release/2.15.27-1 Branch test-master-lock set up to track remote branch master from origin. Branch test-staging set up to track remote branch staging from origin. Initialized empty Git repository in /home/james/Desktop/patchy/lilypond-autobuild/.git/ fatal: attempt to fetch/clone from a shallow repository fatal: The remote end hung up unexpectedly Begin LilyPond compile, commit: 39f50579ff91fdca06acd52a9392ab2874f4723b and I don't know where I need to look from here. Run git fetch --depth=100 in your original repository. That should convert it from a shallow repository to a full one. Thanks, I know that Janek and co are doing more work on Patchy so I haven't run it since, however this may be something useful him. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
James pkx1...@gmail.com writes: Hello, On 24 January 2012 22:20, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: Keeping the staging-merge going would be about five people committing to 50€ a month. That is, of course, not enough for me to live on. It merely means that taking on this duty will not further reduce the amount of time I can spend on LilyPond in total. That would be a waste of your skills. The skills will eventually become unavailable anyway if nobody pays for either major or minor variants of them, so that should be the smallest worry. I have not offered to do it for free, anyway. If the time I spend on that is paid for, it is no loss to anybody. I don't have a 24/7 computer, Neither is a laptop, but I'd still get some stuff done. but if no one else will volunteer i can run Patchy (the skills necessary are quite like mine). I only need to pass my exams - 9 days left till i have lots of time to investigate and improve Patchy (with Julien's help). I have a machine that I can keep running 24/7 (well I have electricity 24/7, Internet connection probably about 20/7) and have already offered (and been trying) to run patchy but with limited success this week. Patchy has been running for about 6 hours on my laptop trying to get the current staging (which is one trivial commit ahead of master) checked. And is still on it. It bogs down development use to a crawl. At least with this (the quite old laptop, about 1Ghz single core, since the last laptop died on me) this is not a serious option for LilyPond development. Even when the replacement laptop arrives, it will not be much of an option if development is to continue. I might see whether I manage to get the laptop with the dead screen working remotely, but I doubt it will take less than 4 hours for a patchy run. So seriously: this needs to move to a different computer if LilyPond development is of concern to you all. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Sunday, January 29, 2012 2:34 PM Subject: Re: somebody needs to run staging before 29 Jan James pkx1...@gmail.com writes: Hello, On 24 January 2012 22:20, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: Keeping the staging-merge going would be about five people committing to 50€ a month. That is, of course, not enough for me to live on. It merely means that taking on this duty will not further reduce the amount of time I can spend on LilyPond in total. That would be a waste of your skills. The skills will eventually become unavailable anyway if nobody pays for either major or minor variants of them, so that should be the smallest worry. I have not offered to do it for free, anyway. If the time I spend on that is paid for, it is no loss to anybody. I don't have a 24/7 computer, Neither is a laptop, but I'd still get some stuff done. but if no one else will volunteer i can run Patchy (the skills necessary are quite like mine). I only need to pass my exams - 9 days left till i have lots of time to investigate and improve Patchy (with Julien's help). I have a machine that I can keep running 24/7 (well I have electricity 24/7, Internet connection probably about 20/7) and have already offered (and been trying) to run patchy but with limited success this week. Patchy has been running for about 6 hours on my laptop trying to get the current staging (which is one trivial commit ahead of master) checked. And is still on it. It bogs down development use to a crawl. At least with this (the quite old laptop, about 1Ghz single core, since the last laptop died on me) this is not a serious option for LilyPond development. Even when the replacement laptop arrives, it will not be much of an option if development is to continue. I might see whether I manage to get the laptop with the dead screen working remotely, but I doubt it will take less than 4 hours for a patchy run. So seriously: this needs to move to a different computer if LilyPond development is of concern to you all. -- David Kastrup I'm in the middle of revising for my main exam on Monday 30th. I'll have far more free time next week, then 2 weeks off the following weeks. I'll try to work out what needs doing on Tuesday. Does patchy just run make and make test, or does it do make doc as well? As you know, David, my Unix and git skills are close to zero, so it might be a good use of your time (or someone else who can do this) to write an idiot's guide to patchy - that might mean I can get up and running in less than a day. I'd be happy to CG-ise these later. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Jan 29, 2012, at 3:46 PM, Phil Holmes wrote: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Sunday, January 29, 2012 2:34 PM Subject: Re: somebody needs to run staging before 29 Jan James pkx1...@gmail.com writes: Hello, On 24 January 2012 22:20, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: Keeping the staging-merge going would be about five people committing to 50€ a month. That is, of course, not enough for me to live on. It merely means that taking on this duty will not further reduce the amount of time I can spend on LilyPond in total. That would be a waste of your skills. The skills will eventually become unavailable anyway if nobody pays for either major or minor variants of them, so that should be the smallest worry. I have not offered to do it for free, anyway. If the time I spend on that is paid for, it is no loss to anybody. I don't have a 24/7 computer, Neither is a laptop, but I'd still get some stuff done. but if no one else will volunteer i can run Patchy (the skills necessary are quite like mine). I only need to pass my exams - 9 days left till i have lots of time to investigate and improve Patchy (with Julien's help). I have a machine that I can keep running 24/7 (well I have electricity 24/7, Internet connection probably about 20/7) and have already offered (and been trying) to run patchy but with limited success this week. Patchy has been running for about 6 hours on my laptop trying to get the current staging (which is one trivial commit ahead of master) checked. And is still on it. It bogs down development use to a crawl. At least with this (the quite old laptop, about 1Ghz single core, since the last laptop died on me) this is not a serious option for LilyPond development. Even when the replacement laptop arrives, it will not be much of an option if development is to continue. I might see whether I manage to get the laptop with the dead screen working remotely, but I doubt it will take less than 4 hours for a patchy run. So seriously: this needs to move to a different computer if LilyPond development is of concern to you all. -- David Kastrup I'm in the middle of revising for my main exam on Monday 30th. I'll have far more free time next week, then 2 weeks off the following weeks. I'll try to work out what needs doing on Tuesday. Does patchy just run make and make test, or does it do make doc as well? As you know, David, my Unix and git skills are close to zero, so it might be a good use of your time (or someone else who can do this) to write an idiot's guide to patchy - that might mean I can get up and running in less than a day. I'd be happy to CG-ise these later. I've gotten in touch with the Univesrity of Paris VIII to see if they can host (a) Patchy. I'll keep all ya'll posted. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Sun, Jan 29, 2012 at 03:34:45PM +0100, David Kastrup wrote: Patchy has been running for about 6 hours on my laptop trying to get the current staging (which is one trivial commit ahead of master) checked. And is still on it. ??? if you look in the build dir, what logs does it have? I mean, I'd expect pretty much any laptop that still boots to be able to complete a full doc build in 6 hours. So seriously: this needs to move to a different computer if LilyPond development is of concern to you all. Agreed, a laptop isn't great for long-term patchy-staging merge, but I'm still surprised it's taking this long. The compile is O(make doc), so asymptotically, any machine that can complete that task can be used in a pinch. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Graham Percival gra...@percival-music.ca writes: On Sun, Jan 29, 2012 at 03:34:45PM +0100, David Kastrup wrote: Patchy has been running for about 6 hours on my laptop trying to get the current staging (which is one trivial commit ahead of master) checked. And is still on it. ??? if you look in the build dir, what logs does it have? I mean, I'd expect pretty much any laptop that still boots to be able to complete a full doc build in 6 hours. I am doing my own development, compiling and checking in parallel. And yes, I have the suspicion that the chipset might not be talking optimally fast to the hard disk. This laptop feels way slower than the 40% or so it should be compared to the one with the dead screen. Agreed, a laptop isn't great for long-term patchy-staging merge, but I'm still surprised it's taking this long. The compile is O(make doc), so asymptotically, any machine that can complete that task can be used in a pinch. Oh, sure, it _can_ complete, and I am reasonably sure than it will in the next half hour. But I have to do a parallel make info for my own current issue if I want to shake out its acceptance problems timely. I am not sure whether the q stuff should be slated for 2.16. It greatly simplifies things and decreases potential for problems, but I don't see people reporting any test results, and it certainly has seen less user contact than my totally new code. But whatever we decide upon, I want to give users a fair chance of receiving the best 2.16 they can get. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
I am not sure whether the q stuff should be slated for 2.16. It greatly simplifies things and decreases potential for problems, but I don't see people reporting any test results, and it certainly has seen less user contact than my totally new code. As soon it is in master, I'll check it. Sorry for not having enough time to do it earlier. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Werner LEMBERG w...@gnu.org writes: I am not sure whether the q stuff should be slated for 2.16. It greatly simplifies things and decreases potential for problems, but I don't see people reporting any test results, and it certainly has seen less user contact than my totally new code. As soon it is in master, I'll check it. Sorry for not having enough time to do it earlier. Its patch is now respective to master (just advanced master after patchy finally completed the tests and barfed out because the Ethernet slipped, but not before having completed all testing). So to let patchy loose on it with the current master, I'll reset its patch status to patch new (though it is obvious that the last patchy failure was again something because of outdated files -- no idea how they get into Graham's system, or whether updates fail there; I'll start the small patchy here for comparison next). But since we don't cut a release branch AFAICS, it is quite pointless to check it as soon as it is in master. That will be the case when the decision has been made already. While it is conceivable that a commit can be reverted when things go awfully bad, it would be good to make the decision before that. So check it out at least once it is in Patch-review orderly. That means that it is regtest-clean, but that does not mean that a feature change will make its main users happy. And I might point out that it was you who _repeatedly_ pressed for q getting fixed because of its importance to you, even if it meant a solution expensive in developer and possibly execution time. When you now can't be even bothered looking at it, I will think thrice before tackling anything which you call important. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
So check it out at least once it is in Patch-review orderly. That means that it is regtest-clean, but that does not mean that a feature change will make its main users happy. OK. BTW, I've meant staging, not master. Sorry for the thinko. And I might point out that it was you who _repeatedly_ pressed for q getting fixed because of its importance to you, even if it meant a solution expensive in developer and possibly execution time. Well, I mainly forced implementation of `q' because I think it's incredibly useful for LilyPond in general, not only for me. When you now can't be even bothered looking at it, I will think thrice before tackling anything which you call important. Hold your horses, David! You are doing a great job, and I follow your development steps quite closely, but there is real life interfering sometimes. Not everybody has the same working patterns as you have. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Werner LEMBERG w...@gnu.org writes: So check it out at least once it is in Patch-review orderly. That means that it is regtest-clean, but that does not mean that a feature change will make its main users happy. OK. BTW, I've meant staging, not master. Sorry for the thinko. Same thing. Once it is in staging, it will move forward _automatically_ to master potentially within hours unless there is a compilation/testing error. And, outdated hardware or not, with few exceptions I tend to make pretty sure that I don't mess up in that area. I would prefer a conscious decision over it was in Patch-review, so it moved into Patch-countdown, and because still nobody bothered to even look at it, it ended up in master, and now nobody can usefully work with q anymore in 2.16. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
OK. BTW, I've meant staging, not master. Sorry for the thinko. Same thing. Once it is in staging, it will move forward _automatically_ to master potentially within hours unless there is a compilation/testing error. Humpf. I wasn't fully aware of this automatism. OK, will apply manually and test soon. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Werner LEMBERG w...@gnu.org writes: OK. BTW, I've meant staging, not master. Sorry for the thinko. Same thing. Once it is in staging, it will move forward _automatically_ to master potentially within hours unless there is a compilation/testing error. Humpf. I wasn't fully aware of this automatism. OK, will apply manually and test soon. Thanks. Note that this does _not_ mean regtests and doc builds: we have automatisms for that. It means running your own files that use this feature, and reading the docs to see whether the docs as well as the new incarnation of the feature make sense to you. Opinions are more important than results here, and results are only important as _experiences_, namely connected with your own, individual work. Don't bother doing the job of the computer. We need that of the human. Thanks -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
[Applying rietveld 5595043 to git afb4c5fb]
It means running your own files that use this feature, and reading
the docs to see whether the docs as well as the new incarnation of
the feature make sense to you.
It was really good that you have been a pain in the neck, since your
patch causes rhythmic problems.
This input
\version 2.15.25
T = #(define-music-function (parser location music) (ly:music?)
#{
\times 2/3 $music
#}
)
\relative c' {
c e g4 r c e g2 ~ |
\T { c e g4 q q } \T { q q q } |
}
gives this warning message
q-bug.ly:11:34: warning: barcheck failed at: 5/12
\T { c e g4 q q } \T { q q q }
|
and yields the attached output.
Werner
inline: q-bug.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Werner LEMBERG w...@gnu.org writes:
[Applying rietveld 5595043 to git afb4c5fb]
It means running your own files that use this feature, and reading
the docs to see whether the docs as well as the new incarnation of
the feature make sense to you.
It was really good that you have been a pain in the neck, since your
patch causes rhythmic problems.
This input
\version 2.15.25
T = #(define-music-function (parser location music) (ly:music?)
#{
\times 2/3 $music
#}
)
\relative c' {
c e g4 r c e g2 ~ |
\T { c e g4 q q } \T { q q q } |
}
gives this warning message
q-bug.ly:11:34: warning: barcheck failed at: 5/12
\T { c e g4 q q } \T { q q q }
|
and yields the attached output.
Cute. Hiding the duration of the repeat chord away in chord-repeat
might not have been such a good idea after all. I'll take a look at how
\times works and likely will change this back, as the durations are more
likely to be found in a duration entry. Hopefully that is enough, or
I'll have some serious head-scratching to do.
Thanks, that was an important help already.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On 12-01-29 11:04 AM, David Kastrup wrote: Werner LEMBERGw...@gnu.org writes: OK. BTW, I've meant staging, not master. Sorry for the thinko. Same thing. Once it is in staging, it will move forward _automatically_ to master potentially within hours unless there is a compilation/testing error. Humpf. I wasn't fully aware of this automatism. OK, will apply manually and test soon. Thanks. Note that this does _not_ mean regtests and doc builds: we have automatisms for that. It means running your own files that use this feature, and reading the docs to see whether the docs as well as the new incarnation of the feature make sense to you. Opinions are more important than results here, and results are only important as _experiences_, namely connected with your own, individual work. Don't bother doing the job of the computer. We need that of the human. Thanks As an interjection from a semi-human part of the process: I ordinarily put patches on countdown rather aggressively, with the inent of keeping them flowing through the system. I could easily restrict countdowns to those patches which have an explicit LGTM from a senior developer. Another approach might be to ask developers to flag their especially critical patches with a needs LGTM. I'm afraid both would slow the patch clearing process, but either should give the sort of explicit review David is seeking. Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Colin Campbell c...@shaw.ca writes: On 12-01-29 11:04 AM, David Kastrup wrote: Thanks. Note that this does _not_ mean regtests and doc builds: we have automatisms for that. It means running your own files that use this feature, and reading the docs to see whether the docs as well as the new incarnation of the feature make sense to you. Opinions are more important than results here, and results are only important as _experiences_, namely connected with your own, individual work. Don't bother doing the job of the computer. We need that of the human. Thanks As an interjection from a semi-human part of the process: I ordinarily put patches on countdown rather aggressively, with the inent of keeping them flowing through the system. I could easily restrict countdowns to those patches which have an explicit LGTM from a senior developer. Another approach might be to ask developers to flag their especially critical patches with a needs LGTM. I'm afraid both would slow the patch clearing process, but either should give the sort of explicit review David is seeking. Either way we have too little developer time to go round. I still decided to belabor Werner on this issue because he basically outed himself as a user and fan of the feature, and I had little else to work with here. Like with the discussion groups: if we don't find a way to have a working trickle-down started for reviews, developers will get congested and exhausted eventually, physically (including their time budget) as well as mentally. It is good that we get into a shape where we need the humans mostly to do the job of humans only. But we can't replace that. And so we'll need more humans. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Hello, On 24 January 2012 22:20, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: Keeping the staging-merge going would be about five people committing to 50€ a month. That is, of course, not enough for me to live on. It merely means that taking on this duty will not further reduce the amount of time I can spend on LilyPond in total. That would be a waste of your skills. The skills will eventually become unavailable anyway if nobody pays for either major or minor variants of them, so that should be the smallest worry. I have not offered to do it for free, anyway. If the time I spend on that is paid for, it is no loss to anybody. I don't have a 24/7 computer, Neither is a laptop, but I'd still get some stuff done. but if no one else will volunteer i can run Patchy (the skills necessary are quite like mine). I only need to pass my exams - 9 days left till i have lots of time to investigate and improve Patchy (with Julien's help). I have a machine that I can keep running 24/7 (well I have electricity 24/7, Internet connection probably about 20/7) and have already offered (and been trying) to run patchy but with limited success this week. I haven't bothered Graham as he is on limited time now, which can be better spent I am sure that walking me through python scripts. However when I run patchy I am getting --snip-- james@jameslilydev2:~/Desktop/patchy$ ./run-lilypond-staging.sh remote: Counting objects: 83, done. remote: Compressing objects: 100% (57/57), done. remote: Total 57 (delta 45), reused 0 (delta 0) Unpacking objects: 100% (57/57), done. From ssh://git.sv.gnu.org/srv/git/lilypond 39f5057..5a61803 master - origin/master ad3a9e6..8019ff7 staging- origin/staging From ssh://git.sv.gnu.org/srv/git/lilypond * [new tag] release/2.15.27-1 - release/2.15.27-1 Branch test-master-lock set up to track remote branch master from origin. Branch test-staging set up to track remote branch staging from origin. Initialized empty Git repository in /home/james/Desktop/patchy/lilypond-autobuild/.git/ fatal: attempt to fetch/clone from a shallow repository fatal: The remote end hung up unexpectedly Begin LilyPond compile, commit: 39f50579ff91fdca06acd52a9392ab2874f4723b etc etc. --- and I don't know where I need to look from here. Bear in mind this is on my lilydev machine where I can manually download/git pull/push etc. So I know it is getting the code but not sure what the other message means because it is coming from git (I cannot find the 'fatal' strings in any of the .py files). I'm struggling to find time between my coffee and cornflakes as well as doing doc patches, so if someone can shed any light or point me somewhere I can move on with Patchy. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Wed, Jan 25, 2012 at 09:10:16AM +, James wrote: Initialized empty Git repository in /home/james/Desktop/patchy/lilypond-autobuild/.git/ fatal: attempt to fetch/clone from a shallow repository fatal: The remote end hung up unexpectedly It wants to have a full git clone git://git.sv.gnu.org/lilypond.git command, as (now) specified in the CG and done in the updated lily-git.tcl. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
James pkx1...@gmail.com writes: However when I run patchy I am getting --snip-- james@jameslilydev2:~/Desktop/patchy$ ./run-lilypond-staging.sh remote: Counting objects: 83, done. remote: Compressing objects: 100% (57/57), done. remote: Total 57 (delta 45), reused 0 (delta 0) Unpacking objects: 100% (57/57), done. From ssh://git.sv.gnu.org/srv/git/lilypond 39f5057..5a61803 master - origin/master ad3a9e6..8019ff7 staging- origin/staging From ssh://git.sv.gnu.org/srv/git/lilypond * [new tag] release/2.15.27-1 - release/2.15.27-1 Branch test-master-lock set up to track remote branch master from origin. Branch test-staging set up to track remote branch staging from origin. Initialized empty Git repository in /home/james/Desktop/patchy/lilypond-autobuild/.git/ fatal: attempt to fetch/clone from a shallow repository fatal: The remote end hung up unexpectedly A shallow repository? That's a git problem, not a Python problem. I would have to look that up. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
somebody needs to run staging before 29 Jan
In order to reduce our bus factor[1] -- especially considering the distinctly non-zero possibility that I'll be gone at the end of March -- somebody else needs to run the Patchy staging-merge script. To make this more presssing, I am refusing to run this script myself after 29 Jan 2012. [1] http://en.wikipedia.org/wiki/Bus_factor Note that there are three separate issues here: 1. more people need to know how to run the script. (it's not hard; far easier than setting up apache) 2. it would be good to have something in the CG about Patchy. 3. somebody needs to set up a cronjob to run it regularly (I suggest every 12 hours). We do not need to have one person doing all three tasks. I am willing to continue running the new patch tests for a bit longer. (probably 1 or 2 weeks after the deadline for staging-merge) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
1. more people need to know how to run the script. (it's not hard; far easier than setting up apache) I can do this if... 2. it would be good to have something in the CG about Patchy. ...you can do this. I also think that Patchy needs to be part of the LilyPond source. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
On Tue, Jan 24, 2012 at 01:08:21PM +0100, m...@apollinemike.com wrote: 2. it would be good to have something in the CG about Patchy. ...you can do this. I have 3.5 hours remaining until Jan 29. Given how often we have emergencies come up, I think I need to reserve my time for those. If nothing horrible happens this week, I could start writing something for the CG next Sunday. (which is too late, obviously) Have you actually *tried* running staging? Patchy should print a message saying I'm copying my default config file to ~/.lilypond-patchy-config-or-something-like-that, you might want to edit a few variables. If you don't ctrl-c and edit that file, it'll probably fail after a few more seconds because I doubt your filesystem is set up the way I have mine... but still, editing that file is not hard. If you've tried those steps, and got stuck somewhere, I'm happy to point out what assumption(s) I made or clear up misunderstandings. But I really don't think you'll run into any major problems. I also think that Patchy needs to be part of the LilyPond source. Too much hassle. Which directory? why include patchy but not XYZ? do we need official countdowns for patches for it? etc. Let's just leave it in github for now. It can always be moved later, but that's not a priority. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
2012/1/24 Graham Percival gra...@percival-music.ca: 1. more people need to know how to run the script. (it's not hard; far easier than setting up apache) I'm working on Patchy with Julien. Please be patient - i have a few exams on university (last one on February 2nd). On Tue, Jan 24, 2012 at 01:08:21PM +0100, m...@apollinemike.com wrote: I also think that Patchy needs to be part of the LilyPond source. +1 2012/1/24 Graham Percival gra...@percival-music.ca: Too much hassle. Which directory? scripts or its own directory why include patchy but not XYZ? We should include everything to reduce bus factor and make contributing easier. I have spent over one hour on learning github, and i'll loose more time because of an ssh issue; similarly with git-cl. These are unnecessary maintenance timewasters you always talk about! Also, collaboration (patch reviewing etc) is difficult now. do we need official countdowns for patches for it? Doesn't matter. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Graham Percival gra...@percival-music.ca writes: In order to reduce our bus factor[1] -- especially considering the distinctly non-zero possibility that I'll be gone at the end of March -- somebody else needs to run the Patchy staging-merge script. To make this more presssing, I am refusing to run this script myself after 29 Jan 2012. I'll hopefully will have received a new laptop by then, but it needs more setup work than the last one (I can't just take over the hard disk like previously, as it is ATA-SATA). It will be a Core duo, but still not really fast. Obviously putting myself responsible here will reduce friction for my own contributions and may lead to work on the patchy-staging process. It would take computer and human resources, however. And I have work of my own I want to achieve with my human resources before going broke, and I am fabulously bad at focusing on more than one project. So a reasonably reliant commitment would be subject to several people (who feel that that is the best investment in LilyPond they can make if they can't invest the time) committing a dependable part of their income regularly. Keeping the staging-merge going would be about five people committing to 50€ a month. That is, of course, not enough for me to live on. It merely means that taking on this duty will not further reduce the amount of time I can spend on LilyPond in total. It would also mean that for some things that go wrong I'll be flaming myself and nobody needs to listen. Wouldn't that alone be worth it? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
2012/1/24 Graham Percival gra...@percival-music.ca: In order to reduce our bus factor[1] -- especially considering the distinctly non-zero possibility that I'll be gone at the end of March -- somebody else needs to run the Patchy staging-merge script. To make this more presssing, I am refusing to run this script myself after 29 Jan 2012. [1] http://en.wikipedia.org/wiki/Bus_factor Note that there are three separate issues here: 1. more people need to know how to run the script. (it's not hard; far easier than setting up apache) I'd like to learn it as a backup. I have not a 24/7 machine to run cron tasks. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
2012/1/24 David Kastrup d...@gnu.org: I'll hopefully will have received a new laptop by then, but it needs more setup work than the last one (I can't just take over the hard disk like previously, as it is ATA-SATA). It will be a Core duo, but still not really fast. Obviously putting myself responsible here will reduce friction for my own contributions and may lead to work on the patchy-staging process. It would take computer and human resources, however. And I have work of my own I want to achieve with my human resources before going broke, and I am fabulously bad at focusing on more than one project. So a reasonably reliant commitment would be subject to several people (who feel that that is the best investment in LilyPond they can make if they can't invest the time) committing a dependable part of their income regularly. Keeping the staging-merge going would be about five people committing to 50€ a month. That is, of course, not enough for me to live on. It merely means that taking on this duty will not further reduce the amount of time I can spend on LilyPond in total. That would be a waste of your skills. I don't have a 24/7 computer, but if no one else will volunteer i can run Patchy (the skills necessary are quite like mine). I only need to pass my exams - 9 days left till i have lots of time to investigate and improve Patchy (with Julien's help). Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: somebody needs to run staging before 29 Jan
Janek Warchoł janek.lilyp...@gmail.com writes: Keeping the staging-merge going would be about five people committing to 50€ a month. That is, of course, not enough for me to live on. It merely means that taking on this duty will not further reduce the amount of time I can spend on LilyPond in total. That would be a waste of your skills. The skills will eventually become unavailable anyway if nobody pays for either major or minor variants of them, so that should be the smallest worry. I have not offered to do it for free, anyway. If the time I spend on that is paid for, it is no loss to anybody. I don't have a 24/7 computer, Neither is a laptop, but I'd still get some stuff done. but if no one else will volunteer i can run Patchy (the skills necessary are quite like mine). I only need to pass my exams - 9 days left till i have lots of time to investigate and improve Patchy (with Julien's help). Sounds like a plan. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
