Hello On 29 August 2012 14:19, Graham Percival <gra...@percival-music.ca> wrote: > On Wed, Aug 29, 2012 at 02:09:43PM +0100, James wrote: >> Just an off-the-cuff suggestion. If we had a 'patch-new-doc' and a >> 'patch-new' label would that be useful and tell patchy if it sees the >> former to build doc as well? > > I suppose so, although people uploading with git-cl would need to > specify that it was a doc patch... or perhaps git-cl could > recognize if Documentation/ or ly/ or scm/ were modified. > > However, I think this is a solution looking for a problem. How > often does a patch fail on staging-merge due to doc issues?
They did reduce significantly since Phil and I were able to run tests quickly. I often would run tests myself after the normal patchy tests simply because I knew a change was significant (like Mike's skyline for instance or Phils reduces black bars and even David's lexer/parser change and I did capture a couple of 'passes tests but fails make doc' problems. So by the time they get in to staging the creases were ironed out. also does a normal 'make' always capture fat-finger texinfo typos? It catches all mine, but I cannot be sure it would in every case. I don't think you can completely reduce the need for some human interaction and you may be right about a 'solution looking for a problem', it just depends on how irritating/difficult it is to manage staging that breaks on a merge because of doc stuff. This usually requires a few back and forth of emails and manual intervention, James _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
