Re: delaying new website after 2.14

[Jan Nieuwenhuizen]

On vr, 2009-07-10 at 16:14 -0700, Graham Percival wrote:
> On Sat, Jul 11, 2009 at 12:42:09AM +0200, John Mandereau wrote:
> > 2009/7/10 Graham Percival <address@hidden>:

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

What about switching/releasing "when it's ready?"  We could even
delay the release a week or so until the website is "ready"?

You could define ready as: the front page is translated in most
every language, and I don't get nasty emails from Jan every day
anymore :-)

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

make dist is especially easy with scons, oh, but even easier
with git: git export lily-x.y.z.tar.gz ?

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

This is really something you'd have to ask Han-Wen.  Also, using
GIT is not a decision carved in stone, as far as I'm concerned.

I think that switching to GIT (from cvs of subversion) is a huge
productivity improvement, at least I know it has been for Han-Wen
and me -- and you know, anything that makes you more productive,
like learning the Emacs, is a no-brainer ;-)

However, I very much argued in favour of bazaar, for the very
reasons you cite.  The bazaar project has as usability, ease of
use and good documentation as a prime goal -- and also does
very well in these areas -- much unlike git.  Although git has
improved a bit here and there, its commands and esp. arguments
are still a complete mess, whereas bzr has made grand strides
performance-wise.

Since we switched to GIT I have been looking into getting a bzr
mirror up for our git sources at launchpad.net, from time to time,
a new effort just failed.

> I just think that the current makefile/stepmake system is a bit
> too far on the "making it hard for future contributors" side.

Yes, in retrospect I think stepmake was a mistake.  What we should
have done, is spend much more effort into pushing stepmake into
GNU make itself.  Apparently it was too early for a project like
that to live on its own, like quagmire is doing now.  Either that,
or just use plain autotools.

The point at the time was -- I remember a big automake rant,
I even looked at fixing automake perl scripts -- that on my
address@hidden box, any change to the configure/make system (and we
had a lot in those early days), cost me 5 minutes or so running
bash and perl over and over again.  Producing several layers of
on-disk caching, UGH (like CMAKE still does, incidentally).
This felt as valuable hacking time going down the drain, just
because GNU said we couldn't use GNU make's wonderful features.
Stepmake did use *all* GNU make's wonderful features, we even
added a few.  And stepmake was instant (except for configure,
which luckily we did not rewrite :-)

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

Possibly I can make up for that if we go the SCons way.  I'll have
a look.

Jan.

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl    | http://lilypond.org