Re: [Lilypond-auto] Issue 2719 in lilypond: Patch: Brain surgery on the build system, first stage

[lilypond]

Comment #15 on issue 2719 by address@hidden: Patch: Brain surgery on  
the build system, first stage
http://code.google.com/p/lilypond/issues/detail?id=2719

I agree with you that "cranking releases out" is the best test, and the few  
releases planned on stable/2.16 before actual stable release 2.16.0 (or .1,  
or whatever its number will be) would be ideal for this IMHO; I'd provide  
quick reaction to fix issues that would arise with these changes.  But  
before thinking of extensive feedback after releases, what about actual  
feedback on all efforts I put to make this patch more testable?  Have you  
tried to run Patchy with proposed changes (comments #9-11), or the test  
procedure in comment #2?  Have you looked at dev/jmandereau branch, using  
gitweb/gitk/git log -pM?  That said, I perfectly understand you'd like to  
spend not too much energy on this big patch to concentrate on the number of  
bugs to be solved for 2.16, but you didn't state it clearly.

If you think 2.16 is releasable within one or two months, and you (or the  
developers that will roll releases from 2.16 branch) don't mind fixing dist  
rolling issues like the ones in the long list in comment #7, I'm fine with  
this patch not going into stable/2.16; now that there is this patch to  
circumvent this repeated human error of forgetting files in the bunch of  
makefiles variables defining the files to be distributed, I'll simply  
ignore GUB distcheckerror reports that might arise in branch(es) that miss  
this patch -- fortunately distcheck errors can be easily fixed by many  
developers here.