Re: Tracker 1686 - Process question - separate Tracker Issues or handlepatches as part of T1686?

[Graham Percival]

On Sun, Nov 06, 2011 at 12:58:53PM -0700, Colin Campbell wrote:
> On 11-11-06 10:41 AM, Phil Holmes wrote:
> >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.

Wait, what?  You're over-run with issues, so you want to do more
work per issue?  it only takes 30 seconds to check if a patch is
in git, so the amount of issue numbers isn't really a big deal
compared to whether or not you have to manually look at stuff.

oh hey, there's another easily-automated task.  We could
automatically check that the git commit is in master, then mark it
verified without any human looking at it.

> >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.

Right.  Which is why I think we shouldn't even *try* to check if
patches actually work or not.  If there's a bug report, then sure,
check if the bug is fixed.  But if it's just a patch without an
attached bug report, then just mark it verified and get on with
other stuff.

apparently we're still demanding too much effort from the bug
squad.  How many new bug squad members have we trained in the past
12 months?  uh-huh.  The current people (other than Brett) on the
bug squad are ridiculously over-skilled for the job.  James should
be working on documentation, Phil and Colin should be checking out
GUB or build stuff or working on automation or stuff like that.

This is not a theoretical concern.  If we'd trained a new set of
bug squad members in the summer, and Phil+Colin spent the past few
months working on GUB, then:
1) we would almost certainly be able to have releases right now
2) GOP would be 10-20 hours ahead of where it is now
3) development process would be smoother, or at least better
defined with less confusion.  That probably could have saved 2-5
hours of Adam Spiers' time, let alone the hours (or even days!)
that David and Mike have lost.
4) I might be able to tell people "yes, GLISS will begin in
January" instead of saying "well, we probably have another 4-6
months of GOP, and by then we'll have at least 3 more crises
that'll chew up a week each4) I might be able to tell people "yes,
GLISS will begin in January" instead of saying "well, we probably
have another 4-6 months of GOP, and by then we'll have at least 3
more crises that'll chew up a week each4) I might be able to tell
people "yes, GLISS will begin in January" instead of saying "well,
we probably have another 4-6 months of GOP, and by then we'll have
at least 3 more crises that'll chew up a week each4) I might be
able to tell people "yes, GLISS will begin in January" instead of
saying "well, we probably have another 4-6 months of GOP, and by
then we'll have at least 3 more crises that'll chew up a week
each, so... maybe September 2012?".

if we have any hope of turning lilypond into a sustainable
project, we NEED to have easy entry into the project, and the bug
squad is an ideal vehicle for that.  20 minutes, twice a week?
People spend more than that on a single weekly TV show.  And 99%
of the job is simply a matter of following a written checklist.
how on earth have we managed to not recruit+train people for
this???

- Graham