lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: automated computing tasks for lilypond


From: James
Subject: Re: automated computing tasks for lilypond
Date: Wed, 29 Aug 2012 14:28:12 +0100

Hello

On 29 August 2012 14:19, Graham Percival <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]