bug-lilypond
[Top][All Lists]
Advanced

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

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


From: Phil Holmes
Subject: Re: Issue 1356 in lilypond: LilyPond-style comments embedded inaScheme expression can't include special characters
Date: Tue, 29 Nov 2011 14:28:45 -0000

"Graham Percival" <address@hidden> wrote in message news:address@hidden
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 CG, 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 of patches we have, this is one of the larger jobs to do, and so it really does waste my time. Unless there is clear agreement to change what we currently do (and I only see one person dissenting) then we go with the current status quo, as documented in the current CG in GIT.

--
Phil Holmes
Bug Squad





reply via email to

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