[IPython-dev] Let's get 0.13 released...

Fernando Perez fperez.net at gmail.com
Mon Jun 11 02:54:00 EDT 2012


Hi all,

I think it's high time we start getting things in gear for a 0.13
release.  We've had a *massive* amount of new work since 0.12, to give
you a quick idea:

(master)dreamweaver[ipython]> git diff rel-0.12 | wc -l
76699
(master)dreamweaver[ipython]> git log --oneline rel-0.12.. | wc -l
1413

1400 commits and a 77000 line diff is bigger than many open source
projects, so it's probably OK for us to release now :)


In order to do that, we basically need to:

1. Decide what new work is *necessary* before the release is ready.
Right now we have zero issues marked as blockers for this milestone:

https://github.com/ipython/ipython/issues?labels=prio-blocker&milestone=7&page=1&state=open

but 12 marked as high priority:

https://github.com/ipython/ipython/issues?labels=prio-high&milestone=7&page=1&state=open

and there may be other things for which we haven't made a proper issue.

2.  Merging PRs in flight.  We have 21 open ones, probably not all of
these need to go in for 0.13.

3. Try to organize the team to do the necessary release work.


Let's look at these questions now.

1. New code that needs to be written.  I'd like to ask everyone to
bring here for discussion any issues (make one on GH if it doesn't
exist) that they feel are *critical* for 0.13.

Personally, I would *love* to see #1905 done (expose worksheets UI) as
I think it would be a major, massive improvement to the notebook and
don't think it's too hard.  I will also try to fix #1904, which is a
serious usability problem right now for some magics and shouldn't be
hard to do (but if anyone beats me with a fix, even better!).

So let's try to decide what from this list really needs to be promoted
to release blocker, and the rest will simply have to get reassigned to
the 0.14 milestone.

2. PRs in flight.  I've tried to tag the ones I think are either
almost done or quite important and viable to finish with a small
amount of effort, with the 0.13 milestone:

https://github.com/ipython/ipython/pull/1825: long output in notebook
https://github.com/ipython/ipython/pull/1849: Octave magics
https://github.com/ipython/ipython/pull/1858: window jumping fix in notebook
https://github.com/ipython/ipython/pull/1865: X11/svg support for R magic
https://github.com/ipython/ipython/pull/1891: Virtualenv cell magic
https://github.com/ipython/ipython/pull/1893: parallel magics improvements

It's only 6 PRs, so with a bit of collective effort, we should be able
to finish them up soon.

Of the remaining 15, if you think one of them is *really* important to
have in before 0.13, please bring it up here for discussion and we'll
see if it's realistic.


3. In the past I've tended to be the bottleneck on that, as I try to
do too much.  It would be great if we can split the load of the work
running up to the release process amongst more people, so that pulling
the trigger at the end is easier.

The main issue is doing lots of test runs, which I think thanks to
Thomas' extraordinary work on testing and CI will be less of an issue
this time, and writing up solid release notes, checking documentation,
etc.

I'd like to know if we have some hands on deck that can volunteer to
help start writing *now* a nice set of release notes/what's new
document.  That work can be done and merged quickly but it's time
consuming, and we have so many new features that having a good
document here, with some nice screenshots and other visual flair,
would be great.  I think I spent easily a day or two writing the one
for 0.12, and I simply don't have that time right now.  But if people
start helping with that, and we merge quickly even partial
contributions to it, we should be able to have a good set of release
notes without anyone having to sacrifice two straight days on it.

So I'd propose that all in the core team who are willing to help out
with this simply make their changes and merge them straight into
master, so others can pull quickly and contribute their own parts.
And let's have a show of hands of *who* might be willing to help here,
so those people can coordinate a bit the work (at least letting each
other know they are going to do it, to avoid a true clash of major
work overlapping by accident).


In terms of a timeline, I'd like to cut a first beta very, very soon,
as in two or three days.  This would start making it clear that we're
serious about the release, and it would give us something we can
mention also on the user list to ask for testers, in particular on
windows.  After the beta, we'll spend a week or so landing PRs for a
first RC, and then we'll have a good idea of how much more work will
be needed for the actual release.

I think the code is in pretty good shape, and this is doable soon, but
I'd like to ask that everyone focus your energy for a short time on
code review, fixing whatever issues we deem critical, and helping out
with the release process.  It's awesome to keep getting new code every
day, but at some point we do need to shift gears into making a release
happen, so that users who don't follow git master like most of us here
do, can also benefit from all these great improvements.

So please pitch in, and let's get this done quickly.  The faster we
make a release, the sooner we can all get back to coding new fun
stuff!

Thanks,

f



More information about the IPython-dev mailing list