Bug triaging

[John A Meinel]

Aaron Bentley wrote:
> Wouter van Heyst wrote:
>>> I've merged and closed a couple of bugs yesterday, and John is clearing
>>> more this day (at quite a pace I might add). Most of the bugs in the
>>> tracker are in an 'untriaged' state. How much of regularly going through
>>> the bugs and accepting/assigning and otherwise changing their status
>>> would be useful? 
> 
> If you've got the will, I say go for it.  Better too much bug tracker
> activity than too little.
> 
> If we had a way to mark tests as 'expected to fail', we could
> differentiate between unfixed bugs and regressions.  So we could merge
> the tests into the mainline without causing test failures galore on
> normal runs.

I think this would be wonderful.

What if we add new member functions:
self.knownFailIf()
self.knownFailUnless()

I'm trying to think about how it should work. Since in one sense the
test should continue, even if the one section failed.
But it really depends on how the test is written (some would expect the
previous section to succeed in order to test the next section).

I agree, it would be nice to have a new classification. Something like:
OK, FAIL, KNOWN

Of course, if you have a test which is supposed to pass, you should have
a classification for accidental success too. :)

I could also see it being done with a decorator. So you would have:

@known_failure
def test_this_fails(self):
  self.failIf(True)

But I don't know how you would integrate it into the test suite.
(Perhaps you would absorb the 'self' object, and use a wrapper).

In my head, a known failure should not cause a traceback on the output,
and should not stop "bzr selftest --one".

John
=:->

> 
> Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051029/1b225cb6/attachment.pgp