lilypond-devel
[Top][All Lists]
Advanced

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

Re: Fw: [Lilypond-auto] Issue 2547 in lilypond: Fix documentation of mak


From: Graham Percival
Subject: Re: Fw: [Lilypond-auto] Issue 2547 in lilypond: Fix documentation of making footnotes work via tweak.
Date: Thu, 30 Aug 2012 12:52:06 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Aug 30, 2012 at 11:38:51AM +0200, John Mandereau wrote:
> every new comment on those issues with old patches will trigger a test.

That's definitely overkill!  What if I post a comment saying "yes,
this patch definitely looks bad"?

> IMHO all issues that have not changed since 2 months and have
> Patch-needs_work should be labeled Patch-abandoned, could we add a
> script for this?

We could, but I think there's a difference between people who work
slow/infrequently vs. abandoned patches.  I mean, Mike's skyline
patch and Ian's guile 2.0 work have probably both seen periods of
not being changed for 2 months, but both are still being worked
on.

I don't think that we should automatically declare patches to be
abandoned.

> > That said, I don't think that Grenouille should be testing
> > Patch-needs_work.
> 
> I do, because from time to time false negatives happen, i.e.
> Patch-needs_work might be set unproperly,

In that case, I would expect the patch author (who should be much
more familiar with his work than any automated script) to manually
set it to Patch-new.  Failing that, any other developer could set
patch-new to trigger a new test if the discussion suggests that
the previous test results are not correct.

> I intially added Patch-countdown to test more patches that anyway had
> not seen regtests comparison put online before, and could remove it now,
> but I'd like to keep looking for Patch-review, to bring the plus of
> putting regtests comparison online.

Sure, but again I think that we can/should rely on humans manually
saying "let's get a new set of test results for this".

- Graham



reply via email to

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