On 11-11-06 10:41 AM, Phil Holmes wrote:
"Ian Hulin" <[email protected]> wrote in message
news:[email protected]...
OK, here's the question, what's better for our
development/bug-tracking/project management process - add a new
tracker for each of the two modules and mark them as blocking 1686, or
put up patch-sets for each of these as part of Issue 1686, and then
when they've been reviewed, counted down and pushed, put up the final
changes to lily.scm and main.cc, and when this one is reviewed,
counted down and pushed, then we can verify the issue.
By the way, the criteria for verifying all of these patches is that
they do no harm when running the LilyPond regression tests using Guile
1.8.
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. 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.
Colin
--
I've learned that you shouldn't go through life with a catcher's mitt on both
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )
_______________________________________________
bug-lilypond mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
