Re: delaying new website after 2.14

[John Mandereau]

2009/7/10 Graham Percival <address@hidden>:
> Unless there's a totally unexpected deluge of help for the website
> from my recent plea on the -user list, I can't imagine it being
> ready for 2.14.  And I can't recommend delaying 2.14 just for a
> new website.

There are a few technical bits too.


> That said, I still think that the new website would better meet
> the needs of most users, so I propose to add a link to the draft
> in 2-3 week. (hosted on lilypond.org/~graham/ )

So, you still would like to sort-of release the new website while
keeping the old one, which will likely confuse visitors. I recently
visited web sites that have experimental and publicly available
new sites, and this always left me a bad image and feeling.


> We'll explain that it's although it's a draft, it might be easier
> for good English readers to find the info they want, but that it
> is still a work in progress and hasn't been translated yet, etc.

This does not outweighs the bad feeling of the cohabitation
between old and new sites IMHO.


> I'd still like to have some changes in the documentation, but I'm
> scaling them back, and I will *NOT* attempt to touch the build
> system again.  I'm going to wait for somebody else to do it.  This
> is not a particularly happy state of affairs, but it's too
> inefficient for me (and others to clean up) to work with the
> makefiles / stepmake system.
>
> I tried adding an SCons build system for the website, but I'm not
> at all impressed by the result after an hour.

Could you elaborate? Your experience is surely valuable if you have
specific points to criticize.


> As an aside, I *really* wish that we had spent the extra effort to
> make the makefiles, python scripts, etc  written in a readible
> fashion.

The Python scripts for postprocessing translations are temporary ugly
hacks; yes, there have been there for too long, but in a few weeks
they'll have been scraped, so I have no motivation to nicely comment
them and name variables. As for other maintenance scripts and makefiles,
I think they are mostly written using well-named variables and in
reasonnably good style, but lack comments indeed. This should be
fixed, but before this it's important to reply to your remarks on
development and
work on bits of the translation infrastructure that have been dela lot delayed.



> IMO, "ease of understanding" is the most important part
> of a build system or build-related script.  Most people helping
> with lilypond these days *don't* know a lot about makefiles,

Then spend some time reading both Lily makefiles and GNU Make
manual; just make sure to plan one week of vacation for this or
spread it across a few months :-P



> python, and perl, so stuff like
>            v = '.'.join (['%d' % vc for vc in v])
> almost guarantees that I'm going to bug the original author(s) for
> any modifications.

I don't understand what's complicated in this line, except that it
changes the type of variable v from a list to a string, which is
often considered as bad style — oh, speaking of, what does
our code janitor thinks here? ;-) I sometimes practise it because
of laziness, but tend to avoid it in long and/or complex code.


> YES, I'm quite capable of wading through the python docs and/or
> adding reams of print commands to that script to understand it
> (web/scripts/format-page.py, for the curious), but that's very
> inefficient.  Better for me to spend an hour processing a few bugs
> and touching up the docs, rather than five hours decyphering
> uncommented confusing code.

Certainly, but makefiles/C++ hacking has so crucial consequences
that each change must be weighed well enough before attempting
changes, which often require to spend more time on understanding
the problem and existing code than actually making changes.