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

[Brian Granger]

>> I think this will take both of us to tackle.  My idea is to start
>> disabling parts of ipdoctest, or run the test suite on small parts of
>> the codebase to try to isolate where the problem is coming from.
>
> After all the time I spent on this one, I think we should  for now
> leave it, since we have an ugly but functional workaround.  Given how
> little explicit coupling there is between the two things, I suspect
> that this will require making a specific branch (to be thrown away
> when done) where we start deleting *tests* until we find which one is
> causing this.  I suspect that it's not the one that raises the error
> but something else up the chain instead.

Yes, let's take a break from this.

>> * For really public facing developer APIs, I will put in a
>> compatibility layer with deprecation warnings.
>
> Big +1 to this.  By the way, in the disentagling front, keep in mind
> my earlier comments about the biggest problems to fix being:

I will need some help identifying the main developer APIs that need to
be handled in this way.  Although, I am hoping that as I dive in, it
will become obvious.

> - ipmaker/iplib: ipmaker is kind of a 'super __init__' mess that needs
> to disappear, folding it into iplib while making the lot be
> rational/comprehensible.

I might wait to do this until I am tacking the issue of removing the
various threading shells.

> - genutils
>
> - making magics standalone

> I hope these pointers help you a bit.

Yep!

>> The only thing that will change in the actual code though will be
>> import statements and all of this will be tested.  No API changes will
>> be combined with this reorganization work.  This reorganization is
>> needed to help us really identify and isolate the things that need to
>> be refactored moving forward
>>
>> But, because this work will move *everything* around, it will be
>> difficult to merge branches back in in an automatic way.  By hand
>> though it might not be too bad to merge things.
>>
>>> 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.
>>
>> Yes, I will absolutely ask for feedback about these plans before
>> starting.  I am working on an IPEP (IPython Enhancement Proposal) that
>> describes my plans.  More details to follow soon...
>>
>>> 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.
>>
>> In theory this is a great idea.  In practice this timescale will cause
>> problems with the work I need to do.  I currently have funding that
>> ends May 1 to work on this and I need to get started immediately.  It
>> is so rare to have dedicated time and $ for this, I don't want to
>> waste the opportunity.  That is basically 4 weeks away.  In reality, I
>> think I should soon just "go for it" and help people to do their
>> merges into my branch by hand.
>
> No problem.  Honestly we need this so badly, that it would be madness
> from my part to get in the way.  So fire away :)

Cool.

> One suggestion: because LP only allows code reviews from logged in
> users/ team members, let's have the bulk of this design discussion on
> list rather than on LP.  I also like better having this archived on
> our main mailing list for searching, etc.  Once we get into actual
> code reviews for merging, we can leave that to happen on LP.

OK, that makes sense, I will try to keep the discussions here.

Cheers,

Brian

> Cheers,
>
> f
>