Sat Jan 28 17:54:50 CST 2012
We should probably add builds of the docs and sdist/bdist if we can,
so we catch breakages of those (like the most recent one), which devs
who use `setup.py develop` often miss. If possible, we should also
include tests run from both `setup.py install` and `setupegg.py
If we find we like Shining Panda (or CI in general) enough, it could
be beneficial to use it as a way to be more conservative/automatic
about test breakages. I see two principal approaches to this:
1. use master as we always have done, but add a 'stable' branch, which
is equivalent to master, but strictly enforces that tests pass. stable
would be generated from master automatically on confirmation that
2. Set up the CI server to merge and test all open pull requests, and
instruct reviewers to check this status before merging. This would be
similar the model in sympy's slick http://reviews.scipy.org.
1. has the advantage of being automatic rather than voluntary (less
vulnerable to "There's no way this tiny change would break anything"),
but 2. fits better in our current pattern.
On Fri, Jan 20, 2012 at 11:53, Fernando Perez <firstname.lastname@example.org> wrote:
> On Fri, Jan 20, 2012 at 3:09 AM, Thomas Kluyver <email@example.com> wrote:
>> I'd link to that same one I linked to, which shows the overview of our test
> OK; can you go ahead and update our front page or should I do it?
>> In the links on the left hand side? For me it just points to
>> https://bugs.shiningpanda.com/ , and it seems like it requires a separate
>> login. I guess they'll remove it quickly if people start trying to report
>> bugs for the projects they host.
>> There's still some things I'd like to get set up - we'd ideally like the
>> test output in xunit format, but our test architecture makes that a bit
> Yes, it's the fact that we run the tests in groups by subprocess.
> There may be a cleaner way to do it so that one can aggregate the
> resulting results objects, I'm not sure.
>> tricky. It's also possible to display coverage, but I ran into some problems
>> with that too. But they're less important.
> Thanks again for this work, even if the report still has limitations,
> it's already great to have!
> IPython-dev mailing list
More information about the IPython-dev