On Sat, Apr 18, 2009 at 08:26:57AM -0600, Carl D. Sorensen wrote: > > On 4/18/09 6:03 AM, "Graham Percival" <gra...@percival-music.ca> wrote: > > > On Fri, Apr 17, 2009 at 09:39:07PM -0600, Carl D. Sorensen wrote: > > Not only that, but with a minimum of effort. IMO, people adding > > new features should only be required to write one .ly file (for > > input/regression/ ); they shouldn't need to do any other manual > > tweaking to get a snippet in input/lsr/. > > This is an interesting thought, but I think it would require significant > reworking of the existing regtests. > > One of the issues with regtests is that when a bug is found, a regtest is > added to demonstrate the bug, and then when it's fixed, the test works > properly. But it's not clear to me that such a bug-identifying regtest > belongs in the manual.
No, no -- when a programmer writes a regtest for a new feature, the minimal "documentation" work is that he copies it or runs a python script or something to put it in the snippets. If he wants to write more docs for it, such as a non-regtest-like snippet for input/new/, or actual NR stuff, that's fine... but IMO those shouldn't be necessary parts of new feature code. > Let's consider another option -- there's a snippet somebody develops in the > LSR that's a neat way to do something. So we want to add it to the manual. > Should it also be added to the regression tests? My first thought is no, Sweet mao no. > but my second thought says that if it's in the manual, we ought to make sure > it continues to work. So I don't know where I come down on it. We make sure it compiles by compiling the docs. We absolutely do not have the resources (in this case, CPU-wise as well as people-wise) to check every single piece of .ly code that's in the git tree for every single release. > > Fixing this could also tie into my long-desired separation of docs > > from code -- we kill input/ entirely. Snippets go in docs/input, > > and regtests go in regression/ or regtests/ or something like > > that. Oh, I also hate the capital letter in "Documentation", so > > I'm wanting "docs/" instead. And the current input/examples/ dies > > completely and is replaced by lsr-derived stuff. And maybe see if > > we can set up lsr on Valentin's new server, if that new server is > > more reliable than the current one. > > > I don't have input/examples in my git tree. Does it still exist? Umm. It's actually worse than I remembered; the "examples" are in input/ directly. They don't even have their own subdirectory! > When we get lsr set up on another server, perhaps we can get multiple copies > set up to handle different LilyPond versions? Sweet mao no. > I think that the major > limitation on lsr right now (other than the fact that it's frequently down) > is that it only supports one version of LilyPond, and currently, it's an old > version (2.10.12). We'd like to have a 2.10 version, a 2.12 version, and > maybe even a 2.13 version. No. No, we wouldn't like that. It would be even more of a support nightmare. LSR should be the latest stable, which means 2.12.something. Valentin is supposed to be coordinating this with Sebastiano, but he's off spending time on other things right now. *scowl* Remember that the stable versions of lilypond mean something now, and they'll be coming out more often. It shouldn't be a big deal to update LSR once every 6-8 months. I'll admit that we might want special tags for snippets which requires 2.x, rather than any y < x. > > And a pony. I really want a pony. > > Don't think you can have one in Singapore. I think it would be a risk for > messing up the streets! No problem; I can add a bucket attached to the rear. That's actually what the horse-drawn carriages in Victoria (my old university city) did. I always wondered what the smell was like for the tourists, sitting directly behind such a bucket... but hey, maybe that just added to the quaint "fake old English" setting. :) Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
