Re: delaying new website after 2.14

[Graham Percival]

On Sat, Jul 11, 2009 at 12:42:09AM +0200, John Mandereau wrote:
> 2009/7/10 Graham Percival <address@hidden>:
> > 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.

Here's my thoughts:
- probably 95% of our users read English well.
- the new website is way better than the old website.  Not so much
  for downloading, but the Introduction, Documentation, and
  Community pages especially are much clearer.
- the English parts of the new website will be ready for 2.14.
- the translation infrastructure may or may not be ready.
- unless we delay 2.14 by a month or two... or four or five... the
  translations won't be ready.

So... do we launch a shiny new 2.14 release with the old sucky
website, resulting in more users sending confused questions?  Or
do we piss off the non-good-English-reading users (and, more
importantly in my mind, the contributors who worked on
translations) by replacing the website?

What about switching to the new website, but adding a note on the
first page to say that it hasn't been translated yet, but those
preferring other languages can browse the old website *here link*?


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

- no native support for texinfo (yet?), so we need to write custom
  Builders.  This results (as far as I can see) a bunch of extra
  framework, which just boils down to re-creating the Makefile
  rules in a more verbose format.

*shrug*
It's quite possible that I missed some vital parts of the SCons
docs.  As I said, I only tried for an hour.  If you're interested,
compare:
web-gop/texinfo/GNUmakefile
web-gop/texinfo/SConstruct
  (which doesn't include all the functionality of the makefile)

In addition, even if we *did* replace the Documentation/ build
with SCons, we'd still need to do some ugly hackery to get "make
dist" to work and whatnot.


Basically, my misadventures on Wed night / Thurs day  (the essay
stuff, not getting much done in SCons, and accidently losing an
hour's worth of stuff in git) left me really dispirited and
disinterested in any future build or python stuff.

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

But IMO this shouldn't be necessary -- just like my complaints
about git.  Jonathan and I *both* lost 1-2 hours of work, and lost
even more motivation, due to git conflicts on Wed.

I'm a computer science guy starting a PhD, and he's a professor of
music.  Yes, neither of us have spent hours reading the git
docs... but why should we require contributors to spend time on
that?  It's a huge turn-off.  We want to work on lilypond, not on
learning shell-script-of-the-week.  Me spending a week reading the
GNU make manual as a prerequisite to moving the Essay into a new
manual so I have space to talk about alterante editors is *not* a
good use of time.  It means that I spend a week *not* doing
anything directly related to lilypond, not to mention the
frustration.

Yes, there's obviously a trade-off.  I don't mind telling new
(doc) contributors that they need to learn some texinfo, and
people doing bugfixes obviously need to learn scheme and/or C++.

And there's also a trade-off between making future changes hard to
do (to discourage casual hacking and/or casual contributors who
might not follow through on their promises), and making future
changes easy to do.  I've almost always argued against wikis, in
part because they make changes too easy.  (the other part is that
it encourages a "leave it to other people" mentality)

I just think that the current makefile/stepmake system is a bit
too far on the "making it hard for future contributors" side.  If
I understood them, I'd spend a few hours rewriting code to make it
easier for other people, so that whenever I left, the remaining
contributors wouldn't have to puzzle through them so much.

It's the old thing about job security as a programmer -- "if you
make it complicated to understand, then you won't be fired... but
you won't be promoted, either".  I always try to make it as easy
as possible to replace myself.

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

uh-huh.  What's v supposed to contain?  What's vc?

This arose because web-gop doesn't do any version substitution
(the @DEVEL-LINK@ and stuff), and I was hoping that I could adapt
scripts/format-page.py to do it.  But after reading a bit of the
script, I decided to leave this for somebody else.

Cheers,
- Graham