[IPython-dev] Victims of our own success, change of strategy needed to get 0.12 released...

[MinRK]

A summary of the ones currently outstanding:

General:
811 (OSError): incomplete, not to be merged
1073 (storemagic/default extensions):
    Proposes extra work to move extensions to Shell from App.  I suggest
letting the extra work wait until after release, and merge this one as-is.
1116 (shlex unicode): BLOCKER
    I believe this is ready as-is.  It needs a rebase, because it's based
on a branch that was already merged via cherry-pick, but that can easily be
done at merge time.  I'd be happy doing this right now.
1120 (vim-ipython):
    This is Paul's, and doesn't touch the core.  We should just merge it,
wherever it is, when we cut the RC, as Paul describes in the PR.
1128 (pylab start menu and profile): BLOCKER
    Minor issue and easy fix, a conversation is all we need. Since we ship
a broken button, it should be merged.
    I think based on Fernando's lates comment on the mailing list, the
recommendation is to remove the pylab profile
    that we ship altogether, and make the start menu item just do `--pylab`.
1129 (unified setup.py):
    Looks perfectly fine to me, but I am wary of a significant change to
setup.py immediately before release.  I would let this one slide, and merge
immediately after release.
1130 (arg_split / ValueError):
    I'd let this one slip.  %timeit is the principally improved magic, and
this particular fix could have unforeseen implications. The right answer
should probably be that some/all magics *do not* use arg_split, which is
really for something else, instead using their own function that behaves
appropriately.
1137 (MPIExec->MPI rename):
    Simple rename of a few launchers, so that the MPILauncher names are
more symmetrical with SGE/MPI/SSH/PBS/LSF.  I would like this in 0.12,
simply because it means the old names won't need to survive in a deprecated
form for as long.
1138 (symlink):
    One line fix in a test, I'll merge it now.
1140 (embed): BLOCKER
    This one is really important, because part of embedding just doesn't
work right now.  It could be ready as-is, I'm just not familiar enough with
the relevant code to be able to tell.

Notebook related:

873 (ReST): incomplete, not to be merged
1079 (login/logout buttons in the notebook):
    The principal issue this fixes is that no login button is drawn during
a read-only view, when login is possible.  You must explicitly visit
    notebook/login in order to login.
    It is incomplete at this point, and principally a convenience
improvement for an uncommon use case.  We need not block on it, but it
would be nice for users of read-only mode for following along.
1125 (notebook logo):
    Still ironing out alignment issues.  It's an aesthetic improvement, so
I wouldn't block on it.
1132 (name field):
    Principally aesthetic improvement to read-only mode.  Looks clean and
simple, should be ready for merge after a quick test.
1135 (custom settings to notebook webapp):
    I think this should be merged.  It's tiny and clean, but makes
customizing the notebook *much* easier, without requiring write access to
the IPython source dir, and is friendlier to environments where serving
static files from a source tree is inappropriate.
1139 (notification):
    Proof of concept, not meant to be merged.

In general, we can't wait for the notebook to be perfect, or we won't get
0.12 out for years.

QtConsole related:

1122 (IPythonWidget.execute_file):
    Fixes a quote-escape issue in IPythonWidget.execute_file, a method that
is used for nothing at all, as far as I can tell.  Looks fine to me, but I
don't know why we have the method at all.

My reading of the list:
blockers: 1116, 1128, 1140
I recommend: 1073, 1120, 1122, 1132, 1135, 1137
should go in if they are finished in time, but shouldn't block: 1079, 1125
recommend pushing to after release: 1129, 1130, 1139

-MinRK

On Sat, Dec 10, 2011 at 14:27, Fernando Perez <fperez.net at gmail.com> wrote:

> Hi folks,
>
> Since we have a fairly small team, I've always tried to avoid having
> separate release branches, as that requires later merging those back
> into the main development line and keeping for a while two truly
> parallel lines of work.  Instead, we've tended to simply stabilize
> master enough to release it and simply continue forward.
>
> But that's just not going to work this time around: we're now victims
> of our own success, and the stream of contributions is arriving faster
> than we can safely merge them and see their impact for a release.
> Serves us well for refactoring the code to be more modular, testable
> and approachable, I guess :)
>
> Now, I do *not* want to cut the enthusiastic contributions we're
> getting, but we do need to have a period where we test a frozen
> version on top of which we strictly apply *only fixes* and no actual
> new code.  Basically we need to move to what many projects do already
> with a release branch that is frozen while master continues evolving,
> and 0.12 will released from that release branch.
>
> So what I'd like to do is to triage, from our list of currently 16
> open PRs, what do we actually want to go into 0.12.  After that list
> is established, we'll try to merge *only those* and will create an
> actual 0.12 branch to further stabilize them.  New PRs can be directed
> to master, but those we'll either merge right away  (if they are done)
> or we'll retarget them to a 0.12 branch we'll push to the main repo.
>
> So let me know which ones you think are either nearly ready or
> important enough to target them for 0.12, and we'll do this.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111210/08a1fcd0/attachment.html>