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

Fernando Perez fperez.net at gmail.com
Mon Jun 2 03:27:13 EDT 2008


Hi everyone,

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.

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...

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.

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'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.

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! ;)

Cheers,

f



More information about the IPython-dev mailing list