On Tue, Aug 04, 2009 at 12:55:05PM +0200, John Mandereau wrote: > Le lundi 03 août 2009 à 05:51 -0700, Graham Percival a écrit : > > I thought the website was going to be built from the stable > > branch? If we're doing that, then let's delete the web branches. > > This just made me come to mind that I'm for not including News in > generated offline docball: if we did, it would either > — require calling docs generation from GUB twice, once for the actual > build, once more for adding a news entry, > — require you to commit to Git a news entry then revert it in case you > notice the build can't make a release. > > There may be other sneaky side effects of merging all of the web site > into the main sources, but I haven't notice them.
Hmm. If that's the only issue, I'm sure we can find a solution. ... at the very minimum, we could omit the news on the home page (that would require one macro/conditional thingie in general.texi), but leave the "Old news" in Community. I mean, nobody could complain about "Old news" not having the current release, right? :) Alternately, the announcement could be committed (to master). Then I could attempt to build. If the build fails, then I yell at people, but leave the announcement in git master -- after all, we'll make a 2.x.y release *eventually*. If the build succeeds, _then_ I backport that commit to stable, which updates the website. > > Overall structure by Graham, with many comments and suggestions > > from -user. Patrick McCarty worked extensively on the css and its > > integration with texinfo. Jonathan worked on the Introduction. > > Patrick Schmidt did further work on the CSS and the Old news page. > > ---- > > I won't but I could add "makefiles and input files organization by > John". I assumed that would be obvious in all the successive patches you made after the import from web-gop. I mean, I figured the import from web-gop would be one patch, then you'd spend anywhere between 1 to 10 patches sorting out the modifications to the build process. If you're planning on making one monolithic patch, then of course you should add yourself to the list. :) > Most of the building infrastructure of the web site is yet to be > done, so don't expect much of lilypond-general output to look good on > master tonight: No problem. > About the discussion on generating examples, let's remember that > generated files in the sources are evil and should be reduced to the > bare minimum. Oh, totally agreed. The only question is whether this qualifies as the bare minimum. :) > We already require lilypond and inkscape for the full > docs build, so let's use them also to generate pictures for the web > site. But we don't require them for building the website on lilypond.org. Do you think we should abandon the hourly cron job? Honestly, that always struck me as a bit unnecessary; I wouldn't mind running a shell script to rsync a new website every few days. > Do you realize how complicated would be the docs building process > for the packager or simple contributor if instead of 'make doc', he had > to cd into a lot of directories directories to call 'make > generated-examples', 'make examples' and whatever? Err, if we kept those 13 png files in git, the contributor wouldn't need to run "make generate-examples". > If we allowed this, > all those secondary targets would also have to generate examples for all > languages; on a long-term perspective, I let you imagine the burden it > would add to commit to Git generated files for 20 languages(I agree that > 20 is optimistic :-) Eh? Why on earth would the Examples change for different languages? IIRC, we currently have French lyrics, Italian musical terms, German titles, Italian lyrics, an English instrument name, Italian instrument names, a Hungarian (?) title, Italian titles, some English lyrics and directions... if there was ever part of the docs that we could say "yeah, we really don't need any translations here", it would be the pngs on Introduction->Examples. Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
