Hi, 2013/8/14 Thomas Morley <[email protected]>: > 2013/8/14 Janek Warchoł <[email protected]>: >> Harm and David N. (and some other people) write lots of very advanced >> (and very helpful!) Scheme functions. These funcitons are improved >> over time, and there is a problem related to that: it's easy to get >> lost in all the email threads about them, and it's not always obvious >> where the most recent version is. >> >> I think that such functions should be tracked by version control, and >> i see two approaches: >> - include them in official LilyPond source as soon as they are >> created. Upside: there's bigger chance that they will be updated when >> there are some changes. Downside: one has to write documentation and >> go through official patch submitting channels. >> - use another repository. What about OpenLilyLib? >> http://www.openlilylib.org/ > > Hi Janek, > > well, if I think one of my functions, definitions etc is worth a > patch, I do so, but ofcourse there's the risk I'm distracted by other > tasks and forget about it or I've no time or ...
sure, i understand. Actually, you said something very important: preparing an "official" patch is a non-trivial task - it requires thinking and focusing. We probably cannot make our patch-accepting policy simpler, so this means that we need to have a simpler means of handling such work. The situation "i have something useful, but i dont' have enough time/energy to get it submitted" should never happen. Submitting useful stuff should be a no-brainer. > The idea of version-control for such functions might be nice. But > because I'm still not very familiar with git I'm feeling kind of > ambivalent. I'd be happy to help you (and anyone else) with git. And as i'm a huge fan of git, i believe that it can solve many problems - probably also this one. > Otoh, it might be an idea to do so for the LSR. > > Though, a lot of my functions, definitions etc are too special-cased, > written to fit some users needs or they are workarounds not worth a > patch. They may not be worth a patch for the official LilyPond code base/documentation, but they are definitely worth being remembered. All of them. This means that we need some place to store such things - something like LSR. > The right place for them would be the LSR, _if_ the LSR would be able > to compile them and not use a LilyPond-version far too old for many of > my ideas. > > There were some insinuations on the list the last months (or was it a > year already?) to upgrade the LSR and yes, one should do so. > But I hesitate to volunteer again for this task. > I initiated the last ugrade and did perhaps the major work, supported > by several developers and the great David Nalesnik. > Though there was only one, I repeat _one_, other user who tried to help: > Philippe Hezaine > > @Philippe > Thanks a lot for trying to help. And let me say: You didn't waste my time! > > So I was annoyed by the lack of help/interest of others and I'm still > pissed off. I understand this. I think that this means that there is some design flaw about how LSR works. I'll think about it more. Janek _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
