Re: Documentation/devel/

[John Mandereau]

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