[IPython-dev] Status of pre-0.10 reviews and merges

Fernando Perez fperez.net@gmail....
Tue Mar 31 17:23:06 CDT 2009


Hey,

On Tue, Mar 31, 2009 at 2:34 PM, Brian Granger <ellisonbg.net@gmail.com> wrote:

[...]

> * Fernando and I need to sort out the ipdoctest nose extension and the
> problems that it is causing with some of our Twisted tests.
>
> If you are working on reviews or branches related to 0.10 please let
> us know where you stand and a timeframe for finishing up.

Thanks for pinging back in: here we had a massive sprint for
neuroimaging.scipy.org (a single merge was over 92000 lines long, to
give you an idea of how much code we moved around :) that I'm only now
recovering again from, as grant deadlines pile up.

Over the next two weeks I'll plug back into this so we can put 0.10
out.  I've been thinking about the twisted bug, and I suspect it has
to do with global state.  The ipdoctest plugin insantiates a real
ipython, and that makes some global changes.  I wonder if those are
confusing twisted somehow.  Can you think of anything in this
direction?


> I want to get these things resolved quickly as I am being paid to work
> on IPython during April these pending merges are currently holding me
> up.  This is because I am going to start making MAJOR changes that
> will make it extremely difficult if not impossible to merge branches
> that are children of our current "trunk."  We don't need to release
> 0.10 for me to get started with this work, but we do need to get these
> branches merged before I branch.

I know we've talked a bit about this, but before we get started on
this major reorganization, let's make sure we do plan it carefully.
For better or worse, while ipython is formally 'pre 1.0' and as such,
all API changes are in principle fair game, we need to ensure we find
a good balance of practicality vs purity.  Just like numpy kept some
Numeric-inspired baggage that wasn't ideal so that users could
transition without unnecessary pain, we should keep the same ideas in
mind.  We should obviously fix the major messes we have (ipmaker is
ridiculous, 3 config systems is crazy, etc), but we should also be
willing to tolerate small warts if they make existing user's lives
easier.

Part of that is communicating a plan for the breakage to everyone in
advance, so that feedback can be provided by all affected before
anything irreversible has happened.

Furthermore, I'd like to suggest that post 0.10 we hold a 'bug and
test weeks' (2-4 max) to see if we could do an 0.11 release where we
basically try to *only* fix existing tickets and add as many tests as
we can, before starting to do major API breakage.

There are reasons for this idea:

- This would leave 0.11 as an as-bugfixed-as-possible stable point of
reference for anyone who might find the upcoming changes too
disruptive for a while.

- By forcing ourselves to write tons of tests (even just blanketing
the codebase with doctests) we would leave the code in a far more
robust position for the upcoming reorganization.  I really think that
the level of code changes you have in mind is a dangerous performance
with our current test coverage being so low for the end-user-facing
parts.  But now that with ipdoctest in place it is *trivial* to write
tests against that functionality, it would be possible to protect the
code better with tests *before* diving in, so that at least there's a
safety net to catch us if we fall.

I realize that this would depend on how much time we can actually
commit to this.  I'd love to do a lot, but my next 12 weeks are
insane: *3* grants to write, another full-week sprint to host here,
and one major conference coming up.  I'm sure others have also hectic
schedules.

But perhaps by putting a hard time limit on it, we can avoid too much
disruption: basically we get done what we get done in that time,
little or lots, and then we move on with the reorganization.

How does that sound?

f


More information about the IPython-dev mailing list