John Whitlock

I'd like some test coverage for FastFixtureTestCase (issue #220) before merging any more fixes - otherwise, it's impossible to tell if these fixes fix anything or break other things.

I also think the way forward is to re-sync w/ the current Django code. I'd like tests for FastFixtureTestCase (issue #220) before I start merging fixes.

I don't think we'll add as an official plugin (https://github.com/erikrose/nose-progressive is a nice, fully featured alternative), but this may make a good example documentation for writing your own plugin.

On TravisCI, the MySQL tests run about the same speed as the PostgreSQL tests, and it seems faster than 15 seconds. Is this better in django-nose 1.4 for you?

Is this still an issue with django-nose 1.4 and a current Django? Does the Django test cases have the same issue?

Probably still broken. Lots of details in https://github.com/coderanger/pyzen/issues/3, would require some deep changes in test suite construction.

Interesting alternative. I'll have to investigate if it still works. April 2, 2012 version of `runner.py` is about [0268292](https://github.com/django-nose/django-nose/blob/0268292328070e7f03070c04861ee0f7216ec76e/django_nose/runner.py#L85-L94) - things have changed, but `_get_options` is still fairly similar to...

+1. I suspect that, once we rip out the Django 1.2-compatible code, and rebase it on 1.4 / 1.7 / 1.8 code, it will look a lot like this.

Is this still an issue? I'm guessing the change is to make nose aware of the changes added by `site.addsitedir`.

This seems simple enough, but I'd like to add a failing then passing test to confirm. I think having a class derived from unitest.TestCase would trigger the bug.