2009/7/10 Graham Percival <gra...@percival-music.ca>: > 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. _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
