Re: Back in the saddle

[Colin Hall]

On Mon, Nov 19, 2012 at 12:53:07AM +0000, Colin Hall wrote:
> On Sun, Nov 18, 2012 at 05:51:10PM -0500, Ralph Palmer wrote:
> > On Sun, Nov 18, 2012 at 4:56 PM, Colin Hall <address@hidden> wrote:
> > 
> > And Colin, could you point me to a refresher course in bug listing? Or
> > should I just check the LilyPond docs?
> 
> Just use the LilyPond CG here:
> 
> http://www.lilypond.org/doc/v2.17/Documentation/contributor/issues
> 
> I wrote some notes for Joseph when he started; I'll forward those on
> if I can retrieve them.

See below for the notes I sent to Joe Wakeling, amended with some comments
from Graham Percival.

Cheers,
Colin.

The purpose of the bug squad is maintaining the Issue Tracker, in
particular filtering out invalid bug reports and detecting fresh
reports of known issues. My experience is that this is extremely time
consuming at first. I was doing 5 to 10 hours per week in the early
months. Yes, I think an hour a week is more likely once you have
settled into it.

You should read the Issues section of the Contributor's Guide:

http://lilypond.org/doc/v2.17/Documentation/contributor/issues

Ideally, dealing with a report goes like this:
At 0 mins: You start reading the bug report.

At 2 mins: You've had a think and one of the following applies:

a) It looks like a bug.
b) You're not sure.
c) It is clearly invalid (see docs for validity tests)

For each case, proceed as follows.

Case (a) It looks like a bug.
Spend up to 2 mins searching the issue tracker in case this is a known
bug. If it's a new one, create a tracker. Reply to the post with a
link to the tracker (the new tracker, or the existing one for a known
bug), which is important so that the rest of the squad can see it has
been dealt with.

Case (b)
You're not sure.  Reply to the post asking for one of the devs to
comment, or clarification from the OP.

Case (c) It is clearly invalid (see docs for validity tests)
Reply to the OP explaining why it is invalid. Be kind. If you can see
what they have missed then make helpful suggestions.

And you're done! This way you can keep it down to 8 to 12 mins per bug
report.

I like to keep the tone of the mailing list extremely polite, even at
the risk of seeming a bit false at times. I think it is important to
thank people for their reports and to also thank the devs when they
pitch in with workarounds and descriptions of correct usage.

Joseph asked if it is typically necessary or desirable for the bug
squad to try and reproduce the bug. Graham suggested: If there's a
report specific to an operating system you don't have, then of course
you don't need to reproduce it.  But if the report is a good Tiny
example, say
> 
> \version "2.14.1"
> {
>   % middle tie looks funny here:
>   <c' d'' b''>8. ~ <c' d'' b''>8
> }

then I'd would like it if you reproduced that bug and uploaded a
--preview png showing the problem.  We have scripts that help you do
this.

Joseph also asked if there were any recommendations for the
appropriate setup here, given that people may be working with
different versions, OS, etc.? To which I replied:

I generally treat the Linux versions as definitive. I use a Win7
64-bit thin client laptop to a physical 32-bit Ubuntu machine and a
VirtualBox 64-bit ubuntu on the same laptop, so those are the three
test systems I have readily available.

-- 

Colin Hall