On Sat, Jul 11, 2009 at 12:42:09AM +0200, John Mandereau wrote: > 2009/7/10 Graham Percival <gra...@percival-music.ca>: > > 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
