[Top][All Lists]

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

Re: the "separate, but integrated" website proposal

From: John Mandereau
Subject: Re: the "separate, but integrated" website proposal
Date: Tue, 04 Aug 2009 12:00:40 +0200

Le mardi 04 août 2009 à 01:12 -0700, Graham Percival a écrit :
> Yes, but what if somebody reads the LM, looks at the source, then
> accuses us of lying when we claimed "no tweaks were used"?  I
> wouldn't blame that person at all!

Of course, I rather meant lilyond-book trickery, which we probably
shouldn't use lilypond-book for the examples (see below).

> You mean "download these PDF" links?  Ick, this is rapidly
> becoming complicated.

It shouldn't be more complicated than the old Examples page, but Python
scripting will be replaced by Texinfo macros you started defining.

>   The point of Examples is to showcase our
> features... ok, it seems like dumping these into LSR and including
> them in Snippets makes more sense.  That'll give you the desired
> source and pdf generation.

After a bit of thinking, it would be easier to call lilypond directly,
as it's currently done for the old Examples.

> Just how much time do you want to spend on buildscript in Aug?

You mean until December? ;-)  More seriously, I'd like to get done with
build system janitoring at the beginning of September, then move to more
interesting aspects of development.

> This is going to add yet more complexity -- to GUB, as well as the
> lilypond build scripts.  Seriously, I think this would add at
> least 20 hours to your workload.  All just to generate 13 png
> images in an alternate way?  Is that /really/ a good idea?
> Since 2.13.4 is being held up because GUB is broken, I don't think
> that extra complexity is a great idea.

Yes, even power users could run lilypond and output-distance on entire
input file directories and detect changes in formatting.  This is a goal
for 2.14, or more reasonnably after 2.14.0.

> Our word "stable" refers to the input syntax, so it still has
> meaning.  I certainly admit that we want to avoid regressions in a
> stable branch, but we already have the regtests (which nobody
> looks at) for this purpose!

Regtests comparisons should be enough to check the regtests, I don't
know if they still work.

> Yes.  I mean, if somebody asked me "hey, want to break this now?",
> I'd say no, of course.  But a regression occurs, I'm not going to
> cry.  And more to the point, I'm not going to expend a lot of
> energy trying to ensure that no regressions occur.  Given the lack
> of *other* people willing expend this effort, I don't think I'm
> unique in this regard.

If you are willing to allow development on stable branch with accepting
regressions, then please put a big fat warning on the download page to
warn about this, otherwise we'll have many complaints from users.  I
think allowing development with regressions in stable branch without
having working regtests comparison is unsane.

> Fair enough -- but could you add a post-build rule to rename
> to ?

Not worth the effort. DIY if you like.

> I ran into problems with score line-width vs. complete paper
> width.  In particular, it was the Vocal music example.

I assume knowing/fixing the paper width is easy, isn't it?


Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée

reply via email to

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