lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: adding snippets manually


From: Carl D. Sorensen
Subject: Re: adding snippets manually
Date: Sat, 18 Apr 2009 09:06:34 -0600



On 4/18/09 8:57 AM, "Graham Percival" <address@hidden> wrote:

> On Sat, Apr 18, 2009 at 08:26:57AM -0600, Carl D. Sorensen wrote:
>> 
>> On 4/18/09 6:03 AM, "Graham Percival" <address@hidden> wrote:
>> 
>> 
>> 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.

Oh, OK.  See, I felt like part of my work for adding the new feature
(complex dash patterns in slurs, and a change in syntax for setting
slur dash patterns) was to add the sections to the NR describing it.  Given
the current organization of the NR, it's really trivial (but then again,
I've been working on docs, and not all developers have).

> 
>> 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.
> 

You're right, obviously.  That's why I'm glad we have you thinking about
issues like this.

>>> 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.
> 

Why is it harder to leave the old version up than to take it down when we
move to the new stable version?  What am I missing?

Carl





reply via email to

[Prev in Thread] Current Thread [Next in Thread]