[IPython-dev] IPython development: course adjustment required

[Prabhu Ramachandran]

Hi,

Fernando Perez wrote:
> This would bring us a number of benefits:
[...]
>  * It would be much easier to explain to people that state of ipython.
>  "IPython is just IPython and now it has parallel computing"  The
> ambitious plans for refactoring, notebooks, frontends are underway,
> but IPython is still just IPython.
> 
>  * The parallel computing stuff would instantly make it into all the
> Linux distros.
[...]
>  * Our entire combined effort (limited as it may be, we have some
> great people on board) can be focused on a single problem, and we can
> all trust that we're working together for the same goal.

I agree with the majority of these benefits.  I really would like to see 
the IPython1 features but am too addicted to IPython0 myself.

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.

My 50 paise.

cheers,
prabhu