Re: the "separate, but integrated" website proposal

[Graham Percival]

On Mon, Aug 03, 2009 at 08:51:55PM +0200, John Mandereau wrote:
> Le lundi 03 août 2009 à 05:51 -0700, Graham Percival a écrit :
> > Well, it depends how you define "tweak".  In the LM, we lean
> > pretty heavily on "tweak = \override and \set" (plus others).
> > Some of those examples definitely *do* use tweaks!
> >
> > I'd rather keep the wiggle room and just say "look at these
> > examples".  Nobody will think that we loaded the images in gimp
> > and changed things!
> 
> I meant applying obscure covnersion steps,

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!

> but they will be difficult to avoid to obtain in the result.
> This makes me remember we should add links to PDFs.

You mean "download these PDF" links?  Ick, this is rapidly
becoming complicated.  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.

> > I'd also rather keep the safety of *not* generating them for every
> > stable release.
> 
> GUB comparison tool output-distance is designed to check such changes
> before releasing, so it could be used for examples too.

Just how much time do you want to spend on buildscript in Aug?
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.

> > - for X months, where X is as large as possible, the "stable"
> >   branch *is* the "main" branch, so there's more changes.
> 
> I agree with this; however, changes that bring regressions should not be
> accepted in stable branch but should be the starting point of a
> development branch.  If you don't have this policy, then the word
> "stable" loses its meaning.

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!

> > - the examples will deliberately do fancy stuff; a small change to
> >   a spacing algorithm or improved slur shape might result in a
> >   manually-placed fingering causing a collision.
> 
> Would you allow any regressions in stable releases?

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.


> > I thought the website was going to be built from the stable
> > branch?  If we're doing that, then let's delete the web branches.
> 
> This means importing all web stuff into the main source tree.  This is
> doable, but the part that will be done by hourly cron job will have to
> be well distinct.  This means much buildscripts hacking and janitoring,
> but this is OK.

Yes.

> > Especially with a generic name like "pictures".  Now, if it
> > was "logos", or possibly "old-and-unused-and-current-logos", then
> > I'd agree.
> 
> I'm lazy about moving directories except with strong justifications.  If
> you really want to, I tell you a recipe for next time:

Thanks, I've used it, and I'll definitely keep this around for any
future changes.

> Noted. I'll work on something clean enough from a source files and
> directory perspective and push general.texi (sorry, there is a directory
> named lilypond/ for Info docs with images build, and I don't want to do
> special casing for MANUAL_SUBDIRS) and its inclusions tomorrow if
> everything goes well.

Fair enough -- but could you add a post-build rule to rename
general.info/pdf/html to lilypond.info/pdf/html ?  I kind-of
expected that the source file couldn't be "lilypond".


> > > I'll hack lilypond-book to produce snippets with preview images
> > > and "click to enlarge/click to see the complete score" links.
> > 
> > ... I'm still really iffy about this.  Both Jonathan and I spent a
> > few hours trying to force lilypond to create images with a
> > specific pixel width (600 pixels, IIRC -- see
> > texinfo/examples/GNUmakefile).  We both failed.
> 
> Ugh. Lilypond already resizes in a similar way as what you put in
> $(SCALE), why don't you calculate the appropriate -dresolution value?

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

Cheers,
- Graham