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 <gra...@percival-music.ca>:
> 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 i...@66mhz 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 <jann...@gnu.org> | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl | http://lilypond.org _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
