[IPython-dev] Development on Launchpad, odds and ends

[Brian Granger]

> I think we're now in decent shape regarding the transition to
> Launchpad (I updated the Trac site and the Moin wiki to reflect this).
>  I still find the Launchpad site a PITA to navigate and find
> information about, but let's hope it will improve as more people use
> it.
>
> We have two official "series" for IPython (these were there before,
> what  I did was change branch structure, not the series):
>
> https://launchpad.net/ipython/trunk
> https://launchpad.net/ipython/stable
>
> They are for now basically copies of each other, since 'stable' is
> also tied to the trunk bzr branch.  I suppose from a a project
> management perspective, we'll just want to make a separate branch for
> stable maintenance if we ever get into backport mode.  We can make
> series for major releases later if really needed.

Thanks for tackling all this Fernando, it needed to be done but it
sounds like it was a bit painful.

> Right now I think the only key topic to clean things up is the
> proliferation of ipython1 branches:
>
> https://code.launchpad.net/ipython
>
> Brian is actively working on -fc, Barry on -cocoa, Min is out of town,
> and we should keep the ipython1-dev one around until the dust settles.
>  But I'd suggest cleaning up a bit what we can if possible.  It will
> give us a better focus for the integration process.  Let's sort out
> what the best process for that merge will be over the next few days...

I will be merging ipython1-fc into ipython1-dev very soon.  The
ipython1-dev branch will probably remain for quite a long time as it
will have all the ipython1 code that is being brought over into
IPython and that will take a while, for some of the more unstable
portions (like the notebook).  There are also some other ipython1
branches that I will 1) either merge into ipython1-dev eventually or
2) delete.

> So let's see how this whole thing moves forward.  I'm going to work on
> preparing the trunk to 'receive' ipython1 code over the next few days,
> I'll  likely do that in a publicly visible branch and periodically
> merge that into trunk.  I'll announce it here as soon as it's up.

This sounds great.  After I merge ipython1-fc into ipython1-dev, I
will begin to pull ipython1-dev things into IPython (in a branch).
Because both of us will be doing pretty heavy things to IPython, lets
make sure we do lots of pushes back to IPython.  We can coordinate
this further when I start to do this.

My initial merging of ipython1 -> IPython will look like this:

ipython1.config -> IPython.config
ipython1.kernel -> IPython.kernel
ipython1.core -> IPython.kernel.core
ipython1.external -> IPython.external (we will need to coordinate this
as some of the externals are already in IPython.

There will be lots of little things to merge in (docs, setup.py) as well.

The code in these parts of ipython1 are very well tested and are
fairly stable.  The other parts of ipython1 (notebook, daemon,
frontend) are less stable and will need to be transitions over to
appropriate branches IPython trunk development.

> One last word: please be careful from now on with trunk.  We don't
> have ipython0/1 anymore, but that means the trunk is that much more
> important.  We'll port over the documentation and tests from ip1 and I
> will add testing support for all the code, so that we can refactor
> cleanly.  We'll  also uniformize the code for calling conventions as
> we go, for documentation quality, docstrings, etc.

I have a good start on a rst based developer guidelines in ipython1
that we an bring into IPython and merge with the info on the moin
page.

> I've subscribed by email to the trunk to keep an eye out on all
> commits.  Please from now on, let's all try to write clean, documented
> and well organized code.  This is the line of the project that we
> expect will live for a long time, so we all want it to be as clean and
> manageable as possible.  No files without top-level docstrings, no
> functions without proper reST docstrings, etc.  I'll be backing off
> improper commits if need be, but hopefully we won't have to get into
> that.  We may eventually consider instituting a formal code review
> system for all patches, but I'm a bit worried that right now we just
> don't have the resources for that, especially when we're faced with a
> period of rapid code merge/churn by only a few people.

I agree that we probably don't have the manpower to do code review,
but subscribing to trunk at least keeps people in the loop.

> But let's all try our best to work for the highest standards of code
> quality.  We'll all benefit.
>
> IPython0/1 are dead.  Long live IPython! ;)

Yes!

Brian


> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>