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 _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
