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

Barry Wark barrywark at gmail.com
Mon Jun 2 14:05:08 EDT 2008


On Mon, Jun 2, 2008 at 9:23 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> 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.

Feel free to (or I can) merge ipython1-cocoa into ipython1-dev or
whatever ipython0 becomes. The only changes in the branch are in
frontends, and all tests for other packages pass so it should be safe
to merge it in.

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

So there will still be a (for now) fundamental difference between
ipython1.kernel.core and IPython.iplib.InteractiveShell?
>
> 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
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>



More information about the IPython-dev mailing list