Hi Graham, Graham Percival wrote:
If anybody doesn't like it (and doesn't know/feel like fixing it), just revert that commit.
Reverting commits is not good for the moral. It's best not to break compilation on master though, so I suggest you create a branch dev/gpercival if you like. That said, I'll keep fixing makefiles for your commits until you can do it yourself.
Anyway, if anybody knows how to fix it, please do.
Done.
OTHER KNOWN PROBLEMS - eventually we might want macros.itexi to be in Documentation/. Or maybe not.
I don't mind where it lives, but let's not duplicate it unless necessary, see Git master history.
- large sections are completely unformatted. Or rather, they're formatted for text files rather than texinfo. I'll fix that one of these days.
I'll insert and format contents from Documentation/TRANSLATION and lilypond.org README.
John: I waffled over whether to add a "Translation" section in Docs and Website, or whether to add a "Translation" chapter which would include a Docs and Website section.
You did the former and that's fine, as many informations on .
Most of all -- and the reason I added this with all its current problems -- I want us to start dumping info here, rather than split between old website info, public emails, wiki, private emails, etc.
Git detailed commit messages are (or should be) one of the most valuable sources of code documentation, e.g. the best way to start documenting makefiles infrastructure is reading the output from
find -name GNUmakefile |xargs git log GNUmakefile.in make stepmake (use -p git flag to read comments in the diffs). > Here's my
thoughts about what your priorities should be, if you give them any weight whatsoever. :)
I'd like to, but besides real life I must also manage the three new French translators.
1. Support the Frogs. They have energy and whatnot, copmletely unlike me right now. Now, I don't think there's anything you can do for them directly. That said,
I will, although I won't react daily.
2. Get GUB setup and working. Whatever bugs you find and fix will be less that I'll encounter. Since I'm using kainhofer, I'll probably find bugs (in x64) that you don't find, but getting GUB more stable will still help.
I'm running a x86_64 box too.
3. If you want to earn my undying gratitude and love, log in to kainhofer (if you can) and get GUB working on that.
If manage to build correct binaries on my machine, I'll leave getting GUB working on kainhofer to somebody else: getting GUB to build on a variety of machines is cool, but not necessary; getting GUB to build on at least one machine by is necessary, though.
2+3: one way or another, we should start releasing more often, and I lack experience at debugging build failures, and don't anticipate having the energy to learn to do so in the next few weeks.
I wouldn't have the energy to coordinate GOP, manage releases and build binaries too; from this point of view, it is understandable that Han-Wen and/or Jan made a distinction of Release Meister and Build Meister jobs on lilypond.org recruitement section.
Cheers, John _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
