[IPython-dev] IPython development: course adjustment required

[Fernando Perez]

On Sat, May 31, 2008 at 11:06 PM, Prabhu Ramachandran
<prabhu at aero.iitb.ac.in> wrote:
> However, I think there are two things that are being mixed up here.  One is
> getting ip1 features in ip0 and the other is the headache of two separate
> development fronts. I think the idea of "backporting" ip1 features to ip0 is
> a great idea but I still see benefit in an experimental tree where you
> experiment on ideas.  Too often, the need for stability bogs down
> interesting work and new developments.  If you mix the two you get the
> benefit of one but loose out on the other.
>
> In my experience with mayavi2, I had the following problem, which is
> somewhat similar.  For mayavi, the trunk is where the other great projects
> that it depended on were being developed and the branches was for stable
> work (branches are released as part of EPD, and in Debian etc.).  This made
> doing any API breaking improvements a *huge* pain and a constant deterrent.
>  This was incredibly frustrating for me as a developer -- I see warts that I
> know I can fix but can't!  For a while everything was trundling along on the
> branch, it took a ton of work to first port everything from branches to
> trunk. Once the trunk worked, it was amazingly liberating.  Immediately, I
> was able to resolve a few issues that plagued the codebase.  Once those were
> done, I was able to cherry pick nice improvements that would not trigger an
> API break and backport them to the branch.  This included a huge amount of
> functionality and tests.  I agree that this can't always be done but the
> cost of my developer-interest is high and if I loose out interest in
> programming for the project, I might as well kill the project.
>
> What I'm saying is that there is a great advantage to having an official
> unstable branch.  While that may or may not be ip1, I do think it is
> important to not blindly merge the two into one just for the sake of the
> benefits.

Thanks for this take on it: I think we should be OK on that front
though.  ip1 and ip0 were unfortunately not really experimental/stable
versions, they were effectively two projects meant to merge at some
point in the future, but with no viable path (with the available time
and resources) for that to happen in one gigantic shot.  What we want
to do now is basically start putting on the trunk of plain ipython the
parts and features of ip1 that work well already, and  gradually morph
ip1 into the architecturally cleaner project (and well tested) that
we've always wanted.

For experimental development, we *will* have proper branches.  Keep in
mind that now we're on bzr, we have the technical support for easy and
comfortable true branch work.  So once this new merged ipython is up
and running (a few weeks), we can call it 'trunk' and then have
branches *off that* where experimental features can be developed.
With this setup, said branches can still merge from trunk as needed
while their neat ideas mature.  That wasn't really viable with the
ip0/ip1 split, since there was no true common ground for merging.

So I do appreciate your concern and don't dismiss it offhand, but I
think we're OK on that front.  But thanks still for the feedback,
these are all things I'd like to keep in mind.

Cheers,

f