[Top][All Lists]

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

Re: Tracker 1686 - Process question - separate Tracker Issues or handlep

From: Ian Hulin
Subject: Re: Tracker 1686 - Process question - separate Tracker Issues or handlepatches as part of T1686?
Date: Sun, 06 Nov 2011 20:20:39 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

Phil and Colin,

Thanks for the prompt responses.

Looks like the cleanest thing to do will be to raise two new trackers,
both of which will block T1686 while they go through patch/review/etc.

The verification criteria for each of them will be to pass regression
tests and do no damage to the LilyPond build when running with Guile V1.8.*.

It'll also give me chance to play with Graham's new git-cl.



On 06/11/11 19:58, Colin Campbell wrote:
> On 11-11-06 10:41 AM, Phil Holmes wrote:
>> "Ian Hulin" <address@hidden> wrote in message
>> news:address@hidden
>>> OK, here's the question, what's better for our
>>> development/bug-tracking/project management process - add a new
>>> tracker for each of the two modules and mark them as blocking 1686, or
>>> put up patch-sets for each of these as part of Issue 1686, and then
>>> when they've been reviewed, counted down and pushed, put up the final
>>> changes to lily.scm and main.cc, and when this one is reviewed,
>>> counted down and pushed, then we can verify the issue.
>>> By the way, the criteria for verifying all of these patches is that
>>> they do no harm when running the LilyPond regression tests using Guile
>>> 1.8.
>> I've recently started an aversion to multiple issues.  The problem is
>> that it's a Bug Squad role to mark them as verified and we're now
>> over-run with issues just tracking patches.  As usual, I'm sure Graham
>> won't agree with me, but I think Squadders should actually check that
>> the patch works if we mark the issue as verified.  Lots of issues -
>> lots of checking.  My personal preference would be to keep the single
>> issue, with multiple patches.
>> If not this, there should be clear instructions at the top of the
>> issue on how to verify.  "Is 1686 verified?  Then verify this one."
> Recognising this may be part of a GOP issue, I agree loudly with Phil on
> the inclusion as a standard part of an issue, the details of how it is
> verified.  I, too, try to make sure a patch actually does what it says,
> not just that it has been pushed to master, and for some issues, the
> verification can be well beyond my notions of what to look for.
> Colin

reply via email to

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