On Tue, Oct 27, 2009 at 3:26 PM, [email protected] <[email protected]> wrote: >> That's done with the special "fixes #N" bit in the commit messages, >> where N is the issue number. Bitbuckets links the tyicket with the >> commits when its pushed there. So we could maybe add the link to the issue >> in CHANGES ? > > I'm not sure what mechanisms we have for this, do you know?
Yes, I use it. I have added this feature in the admin panel, provided by Bitbucket: $ hg ci -m "blablablba fixes #12" -> add a link to the diff in the issue #12 and close it $ hg ci -m "blablablba refs #12" -> add a link to the diff in the issue #12, but don't close it. > >> Although some parts are cleary undertested yet, so even if it's >> unpleasant to add tests in an undertested code base, I am +1 in making the >> tests mandatory when the code is not yet covered for now on > > That was what we discussed at the sprint and I'm doing what I feel is my job > as QA PITA (pain in the ass) by insisting that A> we have tests for anything > fixed and especially not covered and B> that we document the test related to > the fix so that whomever reported the bug can verify that the test does > indeed cover the use-case they reported. > > What is the next step? That sounds very cool ! As the QA master I guess your next steps would be: - to set up a bbot for distribute (you can PV me so we can work on the details with Titus that has offered some slave hosting too) - to watch all commits going on and blame people that don't do tests, or make comments on the quality of the commited code. An extra pair of eyes is great for that. Granted that we could all do that, but QA needs a lead or it slowly dies imho. I think we would all very appreciate it if you could help on this! Tarek _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
