[IPython-dev] Development on Launchpad, odds and ends
Mon Jun 2 13:05:08 CDT 2008
On Mon, Jun 2, 2008 at 9:23 AM, Brian Granger <email@example.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
>> We have two official "series" for IPython (these were there before,
>> what I did was change branch structure, not the series):
>> 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:
>> 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
>> 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! ;)
>> IPython-dev mailing list
> IPython-dev mailing list
More information about the IPython-dev