Re: contributing instructions are misleading!
Le 01/01/2014 20:45, James disait : On 01/01/14 17:50, Jean-Charles Malahieude wrote: I compile on native Fedora. I don't know by how would be multiplied a 90 minutes make -j3 make -j3 doc on my dual-core with 2gigs RAM when launched in a VM. Probably not as much as you think. Assuming you have reasonably modern CPUs with VT-x/d enabled. It's very convenient to use a VM than your own base system, but it does take disk space I guess (for the extra OS). You also get trivial abilities to clone/snapshot and/or freeze VMs that I have found helpful in the past. Indeed before Patchy scripts it was how I used to test patches without having to keep rebuilding a baseline image for the reg test comparisons. My box is now 7 years old and doesn't seem to accept VT-x/d. It is not a problem of space but of resources. I work in local clones with git clone -l -s -n --branch translation . ../Traduc However, how often are you building full doc? And why - when we have others who do this. We have scripts don't we that allow you to build *just* sections or *just* languages instead of everything. It's not like it's mandatory for most, if hardly any, developers. […] I consider it mandatory for translators to build from scratch when updating multiple files, before pushing on the translation branch. Here is my work-flow: 1- update the text and add new texidocs when needed, 2- make -j3 doc LANGS=fr (less than 10 min.) 3- check the logs and proofread in a browser (more fluent reading than source file) 4- commit and push Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Jan 01, 2014 at 07:45:15PM +, James wrote: If you are comfortable with making patches and compiling, LilyDev is probably not for you. If you are not or want a ready-to-go environment and don't care that it's on some 'old' Linux release (i.e. not new and shiny) then LilyDev is perfectly fine. Agreed. Urs: if you didn't get that impression from reading the CG, then could you suggest somewhere to add something to that effect (or maybe just copy James' comment literally) ? We don't actually want to discourage experienced linux users from using their native environment; like you, I would find it a bit insulting if a project really did claim that I wasn't able to set up my own devel environment. That said, we want to make it absolutely clear that sorting out the potentially-complicated build dependencies is not *required* from contributors. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Jan 01, 2014 at 03:47:32PM +0100, Janek Warchoł wrote: 2014/1/1 Graham Percival gra...@percival-music.ca: Not quite. 1) is obvious, but equally important is 1.5) update incorrect info. Remember this latest iteration of interest in the CG happened because one or two new contributors tried to follow the published (incorrect) info, got into trouble, and understandably were irritated. You're right that updating incorrect info is important. However, as far as i remember there's not much _incorrect_ info left - the problem that we have now is more that the information is confusing: duplicated, placed in unexpected places, etc. We rarely (if ever) have perfectly duplicated material. We tend to have duplicated and slightly different material. In such cases, at least one of the duplications contains incorrect info. ... I'll admit that 10 minutes of poking around in the CG didn't find any such instances of duplicated material. CG 1.4 Mentors should be removed, and most of the stuff in CG 14 Administrative policies is probably useless and/or misleading, but I didn't see any obvious huge holes in those 10 minutes. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Zitat von Graham Percival gra...@percival-music.ca: On Wed, Jan 01, 2014 at 07:45:15PM +, James wrote: If you are comfortable with making patches and compiling, LilyDev is probably not for you. If you are not or want a ready-to-go environment and don't care that it's on some 'old' Linux release (i.e. not new and shiny) then LilyDev is perfectly fine. Agreed. Urs: if you didn't get that impression from reading the CG, then could you suggest somewhere to add something to that effect (or maybe just copy James' comment literally) ? We don't actually want to discourage experienced linux users from using their native environment; like you, I would find it a bit insulting if a project really did claim that I wasn't able to set up my own devel environment. That said, we want to make it absolutely clear that sorting out the potentially-complicated build dependencies is not *required* from contributors. Cheers, - Graham I'll give it a shot ASAP. Probably it's only an issue of two or three tiny rewordings, just to give the right *impression*. I think I'm quite clear about how it should be. Unfortunately I'm suffering from Holiday's Disease. That is, as long as the children and particularly my wife are at home I don't have access to a Linux box or in general to a computer with more than 10 minutes of coherent concentration ;-) Any activity that relies on either of these conditions has to wait until next week. And I have to admit that LilyPond documentation/website isn't absolutely on the top of the list. Best Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
2014/1/1 Graham Percival gra...@percival-music.ca: On Tue, Dec 31, 2013 at 06:35:36PM +0100, Janek Warchoł wrote: 2013/12/12 Graham Percival gra...@percival-music.ca: Sorry, this awoke Grumpy Graham. I should have expected that. Yes, you should have. :P Happy new year, BTW. And you too! Anyway, there are two parts to this cg cleanup: 1) removing obsolete info 2) reorganizing things. Not quite. 1) is obvious, but equally important is 1.5) update incorrect info. Remember this latest iteration of interest in the CG happened because one or two new contributors tried to follow the published (incorrect) info, got into trouble, and understandably were irritated. You're right that updating incorrect info is important. However, as far as i remember there's not much _incorrect_ info left - the problem that we have now is more that the information is confusing: duplicated, placed in unexpected places, etc. Reorganizing is a seductively easy thing to propose, but it's dangerous. It's easy to have opinions about how things should be structured, so it's a huge bike-shed debate. Any proposal to change the chapters and sections in the CG will involve at least two weeks of debate on -devel. Can you honestly say that another argument like that would not reduce your motivation? It would be a shame if a bunch of good suggestions got lost (or delayed by a few months) because they were wrapped up in a reorganization patch. Just look at the proposed website changes from a week or two ago. Well, i'll try to be careful about that. In any case, i have little time (and will have less in the next weeks), so i'll drop large-scale reorganization at the moment. As an added bonus, if you make dozens of obviously good updates to the CG over weeks and months, then people will gradually recognize you as an authority on the subject. Then if/when you propose some reorganizations, they'll be less skeptical. I wish i had lots of time so that i could plan long-term investments like that ;-) But you're right about breaking changes into small, self-contained and uncontroversial parts. More thinking and discussion than we had the previous 4 times we reorganized the CG? Quite frankly, i'm pretty sure that i gave CG more thought than all of us combined since Waltrop 2012 ;-) and before Waltrop, I spent 100x more timeeffort on the CG than you did. Your point? Ah, you're absolutely right! My point is The Golden Rule: he who does the work, makes the rules ;-) (of course i don't mean that one who does the work can ignore things the others say) Also, times change and stuff like CG gets out of date - even if it was ok after previous reorganization, it doesn't mean that a new reorganization isn't warranted, don't you think? Not really. We still have contributors who need encouragement and an overview of development. We still (I think) have lilydev, and that's still (I think) no easier way to get started. We still have documentation, a website, programming in C++ and scheme, etc. Granted, the previous plans about having mentors fell apart, so those parts of the CG should be removed. But other than that, I think a reorganization would mostly be a distraction away from fixing incorrect info. I don't mean to remove information about lilydev, docs, programming introduction etc. I'm mostly thinking about moving this info around. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Janek Warchoł janek.lilyp...@gmail.com writes: Ah, you're absolutely right! My point is The Golden Rule: he who does the work, makes the rules ;-) If you define does the work as makes any change which includes _undoing_ previous work, then this can be more succinctly expressed as there are no rules. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Am 01.01.2014 15:47, schrieb Janek Warchoł: 2014/1/1 Graham Percival gra...@percival-music.ca: On Tue, Dec 31, 2013 at 06:35:36PM +0100, Janek Warchoł wrote: 2013/12/12 Graham Percival gra...@percival-music.ca: Sorry, this awoke Grumpy Graham. I should have expected that. Yes, you should have. :P Happy new year, BTW. And you too! Anyway, there are two parts to this cg cleanup: 1) removing obsolete info 2) reorganizing things. Not quite. 1) is obvious, but equally important is 1.5) update incorrect info. Remember this latest iteration of interest in the CG happened because one or two new contributors tried to follow the published (incorrect) info, got into trouble, and understandably were irritated. You're right that updating incorrect info is important. However, as far as i remember there's not much _incorrect_ info left - the problem that we have now is more that the information is confusing: duplicated, placed in unexpected places, etc. I think there is something to this observation, I can confirm that from the perspective of the target group. I'm not ready yet to point to what is wrong, but I can say that the information I needed for my recent work was hard to find and resides in unexpected places. Reorganizing is a seductively easy thing to propose, but it's dangerous. It's easy to have opinions about how things should be structured, so it's a huge bike-shed debate. Any proposal to change the chapters and sections in the CG will involve at least two weeks of debate on -devel. Can you honestly say that another argument like that would not reduce your motivation? It would be a shame if a bunch of good suggestions got lost (or delayed by a few months) because they were wrapped up in a reorganization patch. Just look at the proposed website changes from a week or two ago. Well, i'll try to be careful about that. In any case, i have little time (and will have less in the next weeks), so i'll drop large-scale reorganization at the moment. As an added bonus, if you make dozens of obviously good updates to the CG over weeks and months, then people will gradually recognize you as an authority on the subject. Then if/when you propose some reorganizations, they'll be less skeptical. I wish i had lots of time so that i could plan long-term investments like that ;-) But you're right about breaking changes into small, self-contained and uncontroversial parts. I can second this too (Graham's and Janek's comment). While I was first quite frustrated by the outright rejection of my well-meant and substantial contributions to the website structure recently, we all managed to calm down and continue with a constructive discussion. Now, after my first successfull patches I've gained enough confidence in the review process not to perceive objections as a general unwillingness to change established content/behaviour. And I assume the others have noticed that I'm not stubbornly insisting on my proposals. I have postponed some of the problematic issues (e.g. I completely ignored the navigational structure when updating the Features page), but I will come back later to these once all non-controversial things have been done. At that time I will have gained some authority on the subject and at the same time will see which parts of my original suggestions weren't necessary or could be modified to become non-controversial. Also, times change and stuff like CG gets out of date - even if it was ok after previous reorganization, it doesn't mean that a new reorganization isn't warranted, don't you think? Not really. We still have contributors who need encouragement and an overview of development. We still (I think) have lilydev, and that's still (I think) no easier way to get started. That's a point I'd like to say something about. The CG's insistence on Lilydev can be somewhat offputting. I didn't think I'd need Lilydev and wasn't keen on installing a virtual machine only to run a (presumably outdated) Ubuntu inside an up-to-date Linux. But you're led to believe that LilyDev is the canonical environment for working on LilyPond, and if you dare to go another route you'll be on your own and heading for trouble. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
- Original Message - From: Urs Liska u...@openlilylib.org To: lilypond-devel@gnu.org Sent: Wednesday, January 01, 2014 4:41 PM Subject: Re: contributing instructions are misleading! That's a point I'd like to say something about. The CG's insistence on Lilydev can be somewhat offputting. I didn't think I'd need Lilydev and wasn't keen on installing a virtual machine only to run a (presumably outdated) Ubuntu inside an up-to-date Linux. I don't understand this at all. VMs are superb ways of running any number of different environments on the same desktop, at no risk whatever. FWIW all the current lilypond release builds are done on a VM, since GUB won't run on my 64 bit environment. Why the antipathy to VMs? But you're led to believe that LilyDev is the canonical environment for working on LilyPond, and if you dare to go another route you'll be on your own and heading for trouble. Well - since you're the only one running your specific environment, that's generally true. With a VM that many of us run, it's not. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Am 01.01.2014 18:02, schrieb Phil Holmes: - Original Message - From: Urs Liska u...@openlilylib.org To: lilypond-devel@gnu.org Sent: Wednesday, January 01, 2014 4:41 PM Subject: Re: contributing instructions are misleading! That's a point I'd like to say something about. The CG's insistence on Lilydev can be somewhat offputting. I didn't think I'd need Lilydev and wasn't keen on installing a virtual machine only to run a (presumably outdated) Ubuntu inside an up-to-date Linux. I don't understand this at all. VMs are superb ways of running any number of different environments on the same desktop, at no risk whatever. FWIW all the current lilypond release builds are done on a VM, since GUB won't run on my 64 bit environment. Why the antipathy to VMs? It's not an antipathy against VMs, but it's irritating that you're led to believe you have to download LilyDev while actually you just can add a few things to your existing setup and continue to work in your daily environment. But you're led to believe that LilyDev is the canonical environment for working on LilyPond, and if you dare to go another route you'll be on your own and heading for trouble. Well - since you're the only one running your specific environment, that's generally true. With a VM that many of us run, it's not. Is that true? Most Lilypond devs work in a VM? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Urs Liska u...@openlilylib.org writes: Am 01.01.2014 18:02, schrieb Phil Holmes: - Original Message - From: Urs Liska u...@openlilylib.org But you're led to believe that LilyDev is the canonical environment for working on LilyPond, and if you dare to go another route you'll be on your own and heading for trouble. Well - since you're the only one running your specific environment, that's generally true. With a VM that many of us run, it's not. Is that true? Most Lilypond devs work in a VM? Unlikely. But Lilydev still may be the specific environment with the largest number of users. That does not mean that it is used by a majority. And those using anything else have to take care and feeding into their own hands. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
- Original Message - From: Urs Liska u...@openlilylib.org To: Phil Holmes m...@philholmes.net; lilypond-devel@gnu.org Sent: Wednesday, January 01, 2014 5:07 PM Subject: Re: contributing instructions are misleading! Well - since you're the only one running your specific environment, that's generally true. With a VM that many of us run, it's not. Is that true? Most Lilypond devs work in a VM? As David points out, I didn't say that - merely that many do; so you are just about guaranteed support if you take this route. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Le 01/01/2014 18:07, Urs Liska disait : Am 01.01.2014 18:02, schrieb Phil Holmes: - Original Message - From: Urs Liska u...@openlilylib.org But you're led to believe that LilyDev is the canonical environment for working on LilyPond, and if you dare to go another route you'll be on your own and heading for trouble. Well - since you're the only one running your specific environment, that's generally true. With a VM that many of us run, it's not. Is that true? Most Lilypond devs work in a VM? I compile on native Fedora. I don't know by how would be multiplied a 90 minutes make -j3 make -j3 doc on my dual-core with 2gigs RAM when launched in a VM. Happy new year, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
- Original Message - From: Jean-Charles Malahieude lily...@orange.fr To: Urs Liska u...@openlilylib.org; Phil Holmes m...@philholmes.net; lilypond-devel@gnu.org Sent: Wednesday, January 01, 2014 5:50 PM Subject: Re: contributing instructions are misleading! Le 01/01/2014 18:07, Urs Liska disait : Am 01.01.2014 18:02, schrieb Phil Holmes: - Original Message - From: Urs Liska u...@openlilylib.org But you're led to believe that LilyDev is the canonical environment for working on LilyPond, and if you dare to go another route you'll be on your own and heading for trouble. Well - since you're the only one running your specific environment, that's generally true. With a VM that many of us run, it's not. Is that true? Most Lilypond devs work in a VM? I compile on native Fedora. I don't know by how would be multiplied a 90 minutes make -j3 make -j3 doc on my dual-core with 2gigs RAM when launched in a VM. Happy new year, Jean-Charles I can make doc in a VM in under 15 minutes. It depends on the architecture of the native CPU. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On 01/01/14 17:50, Jean-Charles Malahieude wrote: Le 01/01/2014 18:07, Urs Liska disait : Am 01.01.2014 18:02, schrieb Phil Holmes: - Original Message - From: Urs Liska u...@openlilylib.org But you're led to believe that LilyDev is the canonical environment for working on LilyPond, and if you dare to go another route you'll be on your own and heading for trouble. Well - since you're the only one running your specific environment, that's generally true. With a VM that many of us run, it's not. Is that true? Most Lilypond devs work in a VM? I compile on native Fedora. I don't know by how would be multiplied a 90 minutes make -j3 make -j3 doc on my dual-core with 2gigs RAM when launched in a VM. Probably not as much as you think. Assuming you have reasonably modern CPUs with VT-x/d enabled. It's very convenient to use a VM than your own base system, but it does take disk space I guess (for the extra OS). You also get trivial abilities to clone/snapshot and/or freeze VMs that I have found helpful in the past. Indeed before Patchy scripts it was how I used to test patches without having to keep rebuilding a baseline image for the reg test comparisons. However, how often are you building full doc? And why - when we have others who do this. We have scripts don't we that allow you to build *just* sections or *just* languages instead of everything. It's not like it's mandatory for most, if hardly any, developers. So saying that make doc takes too long for 'me' to develop for LilyPond is not really an argument (not that I am saying you were saying that but I think building doc taking a long time is a non-issue from a developer point of view when we have the likes of me and Phil to test all that for you if needed). However I have to take issue with Urs comment about: --snip-- ... it's irritating that you're led to believe you have to download LilyDev while actually you just can add a few things to your existing setup and continue to work in your daily environment. --snip-- a 'few things'? Seriously? I've built lilydev for the last 3 or 4 iterations and I can tell you it _isn't_ a few things. It's nigh on three quarters of a gig of stuff (build dep, dblatex etc.), oh and you are checking the versions of the installed components aren't you or are you assuming that the upstream repositories are not now containing things that are 'too new' or now break things when they didn't before (gcc I seem to recall had some issues). So no, it really isn't a few things. Besides the fact that this statement is simply not true, it misses the point completely. If you are OK with downloading the latest and greatest tgz of font forge and recompiling it (which you had to do for a long while) as well as oddities like astyle etc., then LilyDev is clearly not for you and I don't see anywhere where '..you're led to believe...' that you have to download LilyDev. The first paragraph of CG 2.0 states: Want to submit a patch for LilyPond? Great! Never created a patch before? Never compiled software before? No problem! This chapter is for you and will help you do this as quickly and easily as possible. I think you (Urs) need CG 1.3 not CG 2.0. However, as I think has already been stated, if you take LilyDev now and put it in a VM you can guarantee the build environment. If you take a random Linux distribution (and let's not even consider Windows or Mac OS) you cannot guarantee anything. I know, I have tried to rebuild a new LilyDev, on and off, for the last few months with different Linux OSes now that trying to use the later Ubuntu versions has so much bloat that I cannot get a disc image less than 1.7GB (lilydev as it is today and as I use today BTW is 600MB). If you are comfortable with making patches and compiling, LilyDev is probably not for you. If you are not or want a ready-to-go environment and don't care that it's on some 'old' Linux release (i.e. not new and shiny) then LilyDev is perfectly fine. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Hi, 2013/12/12 Graham Percival gra...@percival-music.ca: On Wed, Dec 11, 2013 at 01:48:54PM +0100, Janek Warchoł wrote: PS ccing to Graham because he might be interested to know that Someone(TM) is doing Something(TM) to help new contributors! Sorry, this awoke Grumpy Graham. I should have expected that. Quite frankly, when i read your reply 3 weeks ago, i got irritated, but fortunately i didn't have time to answer ;-) and now - after calming down - i have to admit that you make some good points. My proposal was not good enough (and i certainly failed to express myself clearly, because it seems you had slightly misunderstood me). Anyway, there are two parts to this cg cleanup: 1) removing obsolete info 2) reorganizing things. 1) is a no-brainer, and i'll do it now (and push after patchy confirms it isn't broken). 2) will have to wait till i have more time (summer?). After a good deal of thinking, here's how i think CG should be structured. More thinking and discussion than we had the previous 4 times we reorganized the CG? Quite frankly, i'm pretty sure that i gave CG more thought than all of us combined since Waltrop 2012 ;-) Also, times change and stuff like CG gets out of date - even if it was ok after previous reorganization, it doesn't mean that a new reorganization isn't warranted, don't you think? Anyway, guess what? +1 for Graham! :-) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Tue, Dec 31, 2013 at 06:35:36PM +0100, Janek Warchoł wrote: 2013/12/12 Graham Percival gra...@percival-music.ca: Sorry, this awoke Grumpy Graham. I should have expected that. Yes, you should have. :P Happy new year, BTW. Anyway, there are two parts to this cg cleanup: 1) removing obsolete info 2) reorganizing things. Not quite. 1) is obvious, but equally important is 1.5) update incorrect info. Remember this latest iteration of interest in the CG happened because one or two new contributors tried to follow the published (incorrect) info, got into trouble, and understandably were irritated. Reorganizing is a seductively easy thing to propose, but it's dangerous. It's easy to have opinions about how things should be structured, so it's a huge bike-shed debate. Any proposal to change the chapters and sections in the CG will involve at least two weeks of debate on -devel. Can you honestly say that another argument like that would not reduce your motivation? It would be a shame if a bunch of good suggestions got lost (or delayed by a few months) because they were wrapped up in a reorganization patch. Just look at the proposed website changes from a week or two ago. As an added bonus, if you make dozens of obviously good updates to the CG over weeks and months, then people will gradually recognize you as an authority on the subject. Then if/when you propose some reorganizations, they'll be less skeptical. More thinking and discussion than we had the previous 4 times we reorganized the CG? Quite frankly, i'm pretty sure that i gave CG more thought than all of us combined since Waltrop 2012 ;-) and before Waltrop, I spent 100x more timeeffort on the CG than you did. Your point? Also, times change and stuff like CG gets out of date - even if it was ok after previous reorganization, it doesn't mean that a new reorganization isn't warranted, don't you think? Not really. We still have contributors who need encouragement and an overview of development. We still (I think) have lilydev, and that's still (I think) no easier way to get started. We still have documentation, a website, programming in C++ and scheme, etc. Granted, the previous plans about having mentors fell apart, so those parts of the CG should be removed. But other than that, I think a reorganization would mostly be a distraction away from fixing incorrect info. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Am 12.12.2013 05:26, schrieb Carl Peterson:
On Wed, Dec 11, 2013 at 10:35 PM, Graham Percival
gra...@percival-music.ca mailto:gra...@percival-music.ca wrote
Fixing this doesn't require a reorganization. It requires
deleting the two incorrect bits, dumping a @ref{Submitting a
patch} or whatever the @node is called. On a similar note,
there's at least 2 checklists before submitting a patch, at
least 1 of which has obsolete info.
It may not require a reorganization, but is there a clearer, more
concise way of presenting the information to where there is one
truth and we can say, if you want to contribute, go to this page for
the process? I think there needs to be a page that just outlines the
basic process and branches based on what people are doing/using.
For instance, trying to synthesize the information in broad strokes
(and I could be missing, misstating, or overgeneralizing something):
1) You need to be running Linux.
1.1: If you aren't using Linux, you can run Linux within your
current operating system with LilyDev by following these instructions
[link]
1.2: If you're already running Linux, great! Here's how to make
sure you have all the packages and tools needed to work on LilyPond [link]
2) You need to connect to the git repository and download the source
files. To understand what git is, go here [link].
2.1: If you are using the command line, go here [link]
2.2: If you are not comfortable using the command line, go here to
download lily-git.tcl [link]
3) Once you have downloaded the files, begin making your edits. Go
here to see some of our development policies and practices [link]
4) As you edit the code, you will need to make one or more local
commits to your code, to record your changes in a way that can be
eventually integrated into the official source.
4.1: If you are using the command line, go here [link]
4.2: If you are using lily-git.tcl, go here [link]
5) When you finish editing, you need to create patch files that
represent the changes you made
5.1: If you are using the command line, go here [link]
5.2: If you are using lily-git.tcl, go here [link]
6) With your patch files ready, go here for directions on how to
upload your changes for review and eventually submit them to the
source code [link]
In my searching, I didn't find a page that really did this. Section
1.2 of the current CG should theoretically do this (based on the
title), but it mostly just talks philosophically about git.
This is exactly the kind of information I'd need now too. (And being in
that situation I can't offer doing anything about it.)
One particular question I have could be answered in this thread.
If I'm not completely wrong the CG insists on installing and using
git-cl for uploading patches.
But if I'm not mistaken hardly anyone currently uses it.
So _if_ there is a way to upload a patch for review using normal command
line git, email and/or upload forms, I'd really prefer not to use
git-cl, which seems to be rather restrictive (by design).
But of course this should be documented (as 5.1 of Carl's list).
Urs
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Am 12.12.2013 09:42, schrieb Urs Liska: One particular question I have could be answered in this thread. If I'm not completely wrong the CG insists on installing and using git-cl for uploading patches. But if I'm not mistaken hardly anyone currently uses it. So _if_ there is a way to upload a patch for review using normal command line git, email and/or upload forms, I'd really prefer not to use git-cl, which seems to be rather restrictive (by design). But of course this should be documented (as 5.1 of Carl's list). Sorry, I mixed up git-cl and lily-git, the latter being the one that I'd rather not start using. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Urs Liska u...@openlilylib.org writes: Am 12.12.2013 05:26, schrieb Carl Peterson: 1) You need to be running Linux. 1.1: If you aren't using Linux, you can run Linux within your current operating system with LilyDev by following these instructions [link] 1.2: If you're already running Linux, great! Here's how to make sure you have all the packages and tools needed to work on LilyPond [link] It's more like: on a scale of 1 to 5 of being able to work on LilyPond without major hassles, you can use one of the following: current Ubuntu5 Virtual environment LilyDev on Windows, MacOSX, other 4 Most other GNU/Linux distributions4.5 FreeBSD 3.5 Native MacOSX 2 Native Windows0 This is exactly the kind of information I'd need now too. (And being in that situation I can't offer doing anything about it.) One particular question I have could be answered in this thread. If I'm not completely wrong the CG insists on installing and using git-cl for uploading patches. But if I'm not mistaken hardly anyone currently uses it. That's wrong. Every developer I know uses it. The hardly anyone applies to lily-git.tcl, quite a different beast. So _if_ there is a way to upload a patch for review using normal command line git, email and/or upload forms, I'd really prefer not to use git-cl, which seems to be rather restrictive (by design). No, it isn't. lily-git.tcl is. But lily-git.tcl does not do the issue management (at least not that I know of, never having used it), but rather organizes your git repo and caters for pushing eventually. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Am 12.12.2013 10:02, schrieb David Kastrup: This is exactly the kind of information I'd need now too. (And being in that situation I can't offer doing anything about it.) One particular question I have could be answered in this thread. If I'm not completely wrong the CG insists on installing and using git-cl for uploading patches. But if I'm not mistaken hardly anyone currently uses it. That's wrong. Every developer I know uses it. The hardly anyone applies to lily-git.tcl, quite a different beast. So_if_ there is a way to upload a patch for review using normal command line git, email and/or upload forms, I'd really prefer not to use git-cl, which seems to be rather restrictive (by design). No, it isn't. lily-git.tcl is. But lily-git.tcl does not do the issue management (at least not that I know of, never having used it), but rather organizes your git repo and caters for pushing eventually. As written in my other reply I'd already noticed my mistake. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
2013/12/10 Janek Warchoł janek.lilyp...@gmail.com: 2013/12/7 Janek Warchoł janek.lilyp...@gmail.com: i'm infuriated. A new contributor had turned up, read CG and sent his patch to the frogs mailing list, which, as far as i know, is dead (and since lilynet is down, i'm not sure it's actually working at all). I'm so angry that I'll actually go through the CG and update the instructions. a first hotfix was already pushed; i'm working on a bigger cleanup of first 3 chapters now. Unfortunately, due to http://lists.gnu.org/archive/html/lilypond-devel/2013-12/msg00145.html i cannot continue now. Maybe someone would like to finish this? See branch dev/janek/cg-cleanup and the outline in the attachment. Janek PS ccing to Graham because he might be interested to know that Someone(TM) is doing Something(TM) to help new contributors! After a good deal of thinking, here's how i think CG should be structured. The first chapter should contain everything that a contributor should know (including ho to upload patches for review), and if possible it shouldn't contain optional information (for example not everyone needs to use LilyDev, so this should be in a separate chapter). List of sections: 1) Introduction and Quick start remove helpus * Summary (~Summary for experienced developers, but modified) * how stuff is organized - ROADMAP - branch organizaiton * setting up development environment - link to Lilydev - env variables - Initializing a repository - installing git-cl - git setup tips (i.e. showing branch in prompt) * overview of workflow - link to chapter about git - formatting rules (comit messages, indentation) - compiling overview (what was in compiling in lilydev) - uploading a patch for review - getting the patch pushed 2) LilyDev 3) Working with source code to be designed___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Dec 11, 2013 at 01:48:54PM +0100, Janek Warchoł wrote: PS ccing to Graham because he might be interested to know that Someone(TM) is doing Something(TM) to help new contributors! Sorry, this awoke Grumpy Graham. Reorganizing the CG is very much a something should be done, this is something, so can somebody else do this thing. After a good deal of thinking, here's how i think CG should be structured. More thinking and discussion than we had the previous 4 times we reorganized the CG? The first chapter should contain everything that a contributor should know ... so chapter 1 will be 50 pages? (including ho to upload patches for review), and if possible it shouldn't contain optional information (for example not everyone needs to use LilyDev, so this should be in a separate chapter). Is there any solid evidence that a serious contributor finds it difficult to skip over section 2.1 if it's not relevant? 1) Introduction and Quick start * setting up development environment - link to Lilydev - env variables - Initializing a repository - installing git-cl - git setup tips (i.e. showing branch in prompt) But new developers don't need to know anything in there, other than the link to lilydev. Lilydev and git-cl handle everything else. So your goal of everything that a contributor should know and shouldn't contain optional information already failed. I agree that it's really bad that the CG encouraged people to send stuff to the Frogs list. A fix for that was certainly needed. That doesn't imply that yet another round of reorganizing the CG is needed. It would be much more useful to go through the CG and update the content as necessary. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Dec 11, 2013 at 9:54 PM, Graham Percival gra...@percival-music.cawrote: On Wed, Dec 11, 2013 at 01:48:54PM +0100, Janek Warchoł wrote: PS ccing to Graham because he might be interested to know that Someone(TM) is doing Something(TM) to help new contributors! Sorry, this awoke Grumpy Graham. Reorganizing the CG is very much a something should be done, this is something, so can somebody else do this thing. Is there any solid evidence that a serious contributor finds it difficult to skip over section 2.1 if it's not relevant? Speaking as the new contributor whose experience provoked Janek's indignation, here's my perception of things. Just to give my background, while I've not done much direct application (C++, etc.) programming, I spend most of my day in my real job looking at Microsoft Access databases and writing VBA code for those. In my spare time, whatever that is, and with some part time jobs, I do quite a bit of web programming, including writing a records management system in PHP. I'm familiar with version control, though until looking seriously at LilyPond, my VCS of choice was Subversion. To try to recount the process I went through awhile back, I did install LilyDev at first, when I was wanting to virtualize my dev environment on my iMac. Later, I brought out the Linux box I had set up with Debian a year ago and went through the process of updating it so that I could build LilyPond. I was able to connect to git with minimal fuss, and currently use the lily-git.tcl tool to handle commits and patches. All that said, where things got interesting for me was when I wanted to figure out how to submit my patch. Following through the directions in 2.2 (lily-git), I got to this text: Send patch files to the appropriate place: * If you have a mentor, send it to them via email. * New contributors should send the patch attached to an email to fr...@lilynet.net. Please add “[PATCH]” to the subject line. * Translators should send patches to translati...@lilynet.net. * More experienced contributors should upload the patch for web-based review. This requires additional software and use of the command-line; see Uploading a patch for review. At first, I sent the patch to Janek, because the area I was working on (Metafont) was an area he had done some work in and while he doesn't claim to be an expert, I felt that he was someone worth going to, more or less a mentor (and yes, I realize that word and the relationship is defined more concretely elsewhere, but at this point, I don't really see any mentoring going on, which begs the question of whether it should even be mentioned). After taking a look at the patch, he let me know that I really needed to submit the patch myself. So I went to the second option, since I think I meet the definition of new contributor. I told Janek that and copied in the text above in an email, which precipitated what most of you all have seen. I don't know that the organization of the CG is *necessarily* wrong (except where processes are obsolete for various reasons), but I think that instead of providing one concrete workflow for contributing, there are a lot of options offered and described in more or less detail in different places, which can be confusing for anyone who isn't an experienced developer (in the sense of being familiar with git and other such tools). I felt like I was going around in circles and never able to find the same information the same way across multiple times trying to look the information up. Cheers, Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Dec 11, 2013 at 10:20:22PM -0500, Carl Peterson wrote:
I was able to connect to git with minimal fuss, and currently
use the lily-git.tcl tool to handle commits and patches.
Great! This suggests that the introduction in the CG is ok.
All that said, where things got interesting for me was when I wanted to
figure out how to submit my patch. Following through the directions in 2.2
(lily-git), I got to this text:
Send patch files to the appropriate place:
* If you have a mentor, send it to them via email.
* New contributors should send the patch attached to an email to
fr...@lilynet.net. Please add a**[PATCH]a** to the subject line.
* Translators should send patches to translati...@lilynet.net.
* More experienced contributors should upload the patch for web-based
Right. From memory, I think there's 3 different sets of
instructions for submitting a patch in the CG. 2 of them contain
factually incorrect information, and 1 of them was correct as of
summer 2012. That one is probably still correct, but I wouldn't
feel comfortable vounching for it.
Fixing this doesn't require a reorganization. It requires
deleting the two incorrect bits, dumping a @ref{Submitting a
patch} or whatever the @node is called. On a similar note,
there's at least 2 checklists before submitting a patch, at
least 1 of which has obsolete info.
... come to think of it, the whole mentor infrastructure never
got off the ground, so there *is* misleading info in chapter 1.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Dec 11, 2013 at 10:35 PM, Graham Percival
gra...@percival-music.cawrote
Fixing this doesn't require a reorganization. It requires
deleting the two incorrect bits, dumping a @ref{Submitting a
patch} or whatever the @node is called. On a similar note,
there's at least 2 checklists before submitting a patch, at
least 1 of which has obsolete info.
It may not require a reorganization, but is there a clearer, more concise
way of presenting the information to where there is one truth and we can
say, if you want to contribute, go to this page for the process? I think
there needs to be a page that just outlines the basic process and branches
based on what people are doing/using.
For instance, trying to synthesize the information in broad strokes (and I
could be missing, misstating, or overgeneralizing something):
1) You need to be running Linux.
1.1: If you aren't using Linux, you can run Linux within your current
operating system with LilyDev by following these instructions [link]
1.2: If you're already running Linux, great! Here's how to make sure you
have all the packages and tools needed to work on LilyPond [link]
2) You need to connect to the git repository and download the source files.
To understand what git is, go here [link].
2.1: If you are using the command line, go here [link]
2.2: If you are not comfortable using the command line, go here to
download lily-git.tcl [link]
3) Once you have downloaded the files, begin making your edits. Go here to
see some of our development policies and practices [link]
4) As you edit the code, you will need to make one or more local commits to
your code, to record your changes in a way that can be eventually
integrated into the official source.
4.1: If you are using the command line, go here [link]
4.2: If you are using lily-git.tcl, go here [link]
5) When you finish editing, you need to create patch files that represent
the changes you made
5.1: If you are using the command line, go here [link]
5.2: If you are using lily-git.tcl, go here [link]
6) With your patch files ready, go here for directions on how to upload
your changes for review and eventually submit them to the source code [link]
In my searching, I didn't find a page that really did this. Section 1.2 of
the current CG should theoretically do this (based on the title), but it
mostly just talks philosophically about git.
Cheers,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Dec 11, 2013 at 11:26:55PM -0500, Carl Peterson wrote: In my searching, I didn't find a page that really did this. Section 1.2 of the current CG should theoretically do this (based on the title), but it mostly just talks philosophically about git. Sounds good. I've never liked that wall of text in CG 1.2. How about you rename the existing section to something like Introduction to open-source development or Introduction to git, then add a new section that's the kind of overview you suggested. NB: this type of change is minimally invasive, has a well-defined scope, and can be done in an hour without requiring lots of discussion on -devel. By contrast, based on historical evidence, any discussion about reorganizing any document is likely to involve at least 5 hours of emails and has over a 50% chance of somebody's feelings getting hurt. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Dec 11, 2013 at 11:56 PM, Graham Percival gra...@percival-music.cawrote: On Wed, Dec 11, 2013 at 11:26:55PM -0500, Carl Peterson wrote: In my searching, I didn't find a page that really did this. Section 1.2 of the current CG should theoretically do this (based on the title), but it mostly just talks philosophically about git. Sounds good. I've never liked that wall of text in CG 1.2. How about you rename the existing section to something like Introduction to open-source development or Introduction to git, then add a new section that's the kind of overview you suggested. NB: this type of change is minimally invasive, has a well-defined scope, and can be done in an hour without requiring lots of discussion on -devel. By contrast, based on historical evidence, any discussion about reorganizing any document is likely to involve at least 5 hours of emails and has over a 50% chance of somebody's feelings getting hurt. Once I have the current website/documentation patch through and the one that I need to redo properly (which was the original one that got me into the dev side), I'll start taking a look at this. The timing also has the advantage of letting me work through a couple of reviews myself to understand this end of the process better before I look at documentation that touches the process. Why can I never remember the old adage about suggestions? Never make a suggestion you aren't willing to implement. :) Oh, well. As they say, it builds character. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
2013/12/7 Janek Warchoł janek.lilyp...@gmail.com: i'm infuriated. A new contributor had turned up, read CG and sent his patch to the frogs mailing list, which, as far as i know, is dead (and since lilynet is down, i'm not sure it's actually working at all). This is absolutely unacceptable. Not only is our contributing process complicated, but the instructions we give are misleading! I'm so angry that I'll actually go through the CG and update the instructions right now, and will push directly to staging. I don't want to waste time on discussions this time, and i dont' actually have time to go through formal review. Any comments and adjustments are welcome - please just send follow-up patches. a first hotfix was already pushed (http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=fcad9f183bb05f7206427bf5fc1b95fd8209d26e) and i'm working on a bigger cleanup of first 3 chapters now. Misleading information, fear me! best j PS it seems that i overcame my prejudice and actually did `make doc`. It's helpful :) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Janek Warchoł janek.lilyp...@gmail.com writes: a first hotfix was already pushed (http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=fcad9f183bb05f7206427bf5fc1b95fd8209d26e) and i'm working on a bigger cleanup of first 3 chapters now. Misleading information, fear me! best j PS it seems that i overcame my prejudice and actually did `make doc`. It's helpful :) It's also unnecessary unless you are including @lilypond passages or working on translations. Plain `make' will build all the English manuals without included scores and will show Texinfo syntax errors. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
contributing instructions are misleading!
hi, i'm infuriated. A new contributor had turned up, read CG and sent his patch to the frogs mailing list, which, as far as i know, is dead (and since lilynet is down, i'm not sure it's actually working at all). This is absolutely unacceptable. Not only is our contributing process complicated, but the instructions we give are misleading! I'm so angry that I'll actually go through the CG and update the instructions right now, and will push directly to staging. I don't want to waste time on discussions this time, and i dont' actually have time to go through formal review. Any comments and adjustments are welcome - please just send follow-up patches. If anyone doesn't like what i'm going to do, please protest swiftly. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On 07/12/13 17:15, Janek Warchoł wrote: hi, i'm infuriated. A new contributor had turned up, read CG and sent his patch to the frogs mailing list, which, as far as i know, is dead (and since lilynet is down, i'm not sure it's actually working at all). This is absolutely unacceptable. Not only is our contributing process complicated, but the instructions we give are misleading! I'm so angry that I'll actually go through the CG and update the instructions right now, and will push directly to staging. I don't want to waste time on discussions this time, and i dont' actually have time to go through formal review. Any comments and adjustments are welcome - please just send follow-up patches. If anyone doesn't like what i'm going to do, please protest swiftly. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel Just make sure you do a make doc before pushing. Else this just screws up the whole patch testing/merge staging if you break something. I cannot tell you how many times someone has broken doc because they weren't careful and just assumed a 'make' is good enough. I don't know why you cannot just make a patch and run it through the normal process - if only for testing - I usually am around in a 24 hour period to test patches if no one else is. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: LilyPond Development Team lilypond-devel@gnu.org Sent: Saturday, December 07, 2013 5:15 PM Subject: contributing instructions are misleading! hi, i'm infuriated. A new contributor had turned up, read CG and sent his patch to the frogs mailing list, which, as far as i know, is dead (and since lilynet is down, i'm not sure it's actually working at all). This is absolutely unacceptable. Not only is our contributing process complicated, but the instructions we give are misleading! I'm so angry that I'll actually go through the CG and update the instructions right now, and will push directly to staging. I don't want to waste time on discussions this time, and i dont' actually have time to go through formal review. Any comments and adjustments are welcome - please just send follow-up patches. If anyone doesn't like what i'm going to do, please protest swiftly. best, Janek The CG is developer material. Feel free to correct it and push to staging _if_ you've checked it with a full make _and_ a make doc. I frequently do. If you can't check with make/make doc, create a patch and let James test it and then push without countdown. Remember, it's only wrong because you, me, David and everyone else who contributes didn't notice it and correct it. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
