[Top][All Lists]

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

Re: Issue 1356 in lilypond: LilyPond-style comments embedded inaScheme e

From: Carl Sorensen
Subject: Re: Issue 1356 in lilypond: LilyPond-style comments embedded inaScheme expression can't include special characters
Date: Tue, 29 Nov 2011 20:22:11 +0000
User-agent: Microsoft-MacOutlook/

On 11/29/11 7:28 AM, "Phil Holmes" <address@hidden> wrote:

>"Graham Percival" <address@hidden> wrote in message
>> On Mon, Nov 28, 2011 at 06:05:35PM -0700, Colin Campbell wrote:
>>> On 11-11-28 11:39 AM, Phil Holmes wrote:
>>> >This presumes that the Bug squad can and do run Git, which is a
>>> >false presumption.
>> +1
>>> More specifically, I believe it requires a Linux build environment,
>>> to be truly effective.
>> If you want to test that the patch actually does what it claims to
>> do, then yes.  If you just want to check if the patch exists in
>> master, then of course it's not necessary.
>>> OTOH, with the lilybuntu VM and lily-git.tcl, doing
>>> "Update source", drop to a shell, cd ~/lilypond-git/build and
>>> running make, should be within reach for most of the sort of folk
>>> who want to be bug squadders.
>> I honestly believe that less than 50% of bug squad volunteers are
>> actively working after 4 weeks.  Am I incorrect as a matter of
>> fact?
>I don't know the history.  I believe the current squad, as shown on the
>has 100% active members.
>> Assuming that I'm not factually incorrect here, we should not make
>> it harder for bug squad volunteers to get started.  Once we hit
>> 80% retention of volunteers after 4 weeks, I'm open to increasing
>> the difficulty.  I would hope that this goal is easy -- as long as
>> we're up front about what's required, maintain an encouraging
>> environment where questions are welcome (within the bug squad, and
>> I'm not claiming to be interested in taking part in that), and
>> ruthlessly update the CG section on Issues -- but it *does*
>> require skilled developers mentoring new volunteers.
>> Short term: sure, let's make "verify a patch" only a task for the
>> bug meister.  The bug meister can either check patches in master
>> via git, or else just mark any Patch issue as verified without
>> checking anything.
>Whoa.  I've just trained the new squadders to do this based on what was
>_agreed_ wrt checking the patch was pushed to staging.  With the volume
>patches we have, this is one of the larger jobs to do, and so it really
>waste my time.  Unless there is clear agreement to change what we
>do (and I only see one person dissenting) then we go with the current
>quo, as documented in the current CG in GIT.

I think that Graham meant "verify a patch that doesn't have an obvious
change to verify", i.e., patches whose only verification is verify that
the patch was applied.

Those that can be verified through changed documentation or fixed regtests
could easily keep going as they have historically.



>Phil Holmes
>Bug Squad

reply via email to

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