[IPython-dev] Proposal: soft moratorium on re-architecting for 5.0

Mon Jun 29 14:23:40 EDT 2015

On Mon, Jun 29, 2015 at 11:15 AM, Brian Granger <ellisonbg at gmail.com> wrote:

> I am +1 on having separate branches for ongoing 4.x work that include
> more than just bug fixes - especially for the notebook and widgets. I
> have a slight preference to have master always be the newer stuff, but
> don't feel too strongly about that.
>

I think there's typically a transition point. For instance, we had
long-running experiment/dev branches for kernel/qtconsole, notebook, and
zmq-based IPython.parallel that weren't master. I think once these things
become "good enough" they can hop over to master, and the minor-release
branches can be bumped. We typically try to live in a "master always works"
state, and some of these things can take a while to get there, in which
case a feature branch is appropriate for the early stages of development.
They can then become master once ready for "primetime", which is to say
that we expect most IPython/Jupyter devs to be using it by default. But in
general, I agree that master == newer stuff, as long as it's usable.

-MinRK

>
> On Mon, Jun 29, 2015 at 10:54 AM, Jonathan Frederic
> <jon.freder at gmail.com> wrote:
> >> I wanted to +1 the proposal to start creating branches for new versions
> >> when a feature freeze occurs.
> >
> >
> > +1 here too, I'm going to do that with ipywidgets for SciPy, create a 5.x
> > branch.  There's a lot of stuff I want to get a jump start on, and SciPy
> is
> > a great time to do it.  I don't want it to end up like numerous other
> > experiments, which end up getting thrown out and redone completely just
> > because of stagmentation and rebase difficulty.
> >
> > WRT to the documentation debt, I think it's important to remind everyone
> > that that is intentional!  I've looked at adding JS docs a couple times
> now,
> > but when I brought it up we've decided as a group that it was lower
> priority
> > because we did not want to commit JavaScript APIs that we know will
> change.
> >
> > I think when we figure out how the front-end packaging and component
> > refactor will work, we definitely want to commit to **something**.
> >
> > On Mon, Jun 29, 2015 at 7:04 AM, Sylvain Corlay <
> sylvain.corlay at gmail.com>
> > wrote:
> >>
> >> I wanted to +1 the proposal to start creating branches for new versions
> >> when a feature freeze occurs. Independently of the discussion on
> phosphor, I
> >> completely agree with Min on the diagnosis that there is not enough
> >> available parallel work.
> >>
> >> Regarding phosphor and the work on refactoring the front-end, thanks for
> >> creating the centralized phosphor notebook repository in the
> organization. I
> >> did some experiments lately with the widgets and did not know where this
> >> could fall, or how to share it without requiring it to install phosphor
> etc.
> >> Coordination is also important for new developments, even when they
> have not
> >> yet achieved the stability of the main components of the project.
> >>
> >> Best,
> >>
> >> Sylvain
> >>
> >>
> >>
> >> On Mon, Jun 29, 2015 at 9:25 AM, Jason Grout <jason at jasongrout.org>
> wrote:
> >>>
> >>> On 6/26/15 19:45, Fernando Perez wrote:
> >>>
> >>> While I hear very much the spirit of what you are saying, and I
> >>> certainly think that we can't lose sight that the *only* thing that
> >>> ultimately matters is whether we serve our users well or not, there's a
> >>> big piece that is already burning under us that probably can't wait.
> In
> >>> fact, at the last dev meeting, Jason already posted his new draft code
> >>> in this direction:
> >>>
> >>> https://github.com/jasongrout/phosphor-notebook
> >>>
> >>>
> >>> I just wanted to mention that I support what Fernando, Brian, and Chris
> >>> have said about moving forward with refactoring the notebook.  We're
> making
> >>> good progress, even while still ramping up.  For example, Steven
> Silvester
> >>> has put a lot of work recently in porting over the kernel javascript to
> >>> Typescript and phosphor (along with dependencies):
> >>>
> >>> https://github.com/jasongrout/phosphor-notebook/pull/2
> >>>
> >>> I just put in an in-progress pull request for documenting the API for
> >>> kernels, kernelspecs, and sessions (which I realized when looking at
> the
> >>> kernel javascript file was woefully undocumented/incorrectly
> documented):
> >>> https://github.com/jupyter/notebook/pull/173.  This shows our
> refactoring
> >>> work is also having an immediate direct impact on the current notebook
> as
> >>> well.
> >>>
> >>> In another message on this thread, Min suggested having a 5.x branch
> for
> >>> further development, like the phosphor notebook.  For now, I think the
> >>> phosphor notebook can proceed as a separate project - it's totally a
> >>> front-end thing at this point, and we're doing enough code clean-up and
> >>> rewriting from js to typescript that I think it's all right to start
> in a
> >>> fresh repo.  Which brings up another point:  can we make an official
> Jupyter
> >>> repo for the phosphor notebook work, rather than using my personal
> repo?
> >>> I'm happy to continue hosting
> >>> https://github.com/jasongrout/phosphor-notebook/ in my personal github
> >>> account for the time being, or set up a temporary organization so we
> can
> >>> collaborate more effectively, but I think it would make more sense to
> bump
> >>> it up to an experimental repo in the jupyter github organization,
> developed
> >>> in parallel with the current notebook.
> >>>
> >>> Thomas, one thing to consider is that us working on a phosphor notebook
> >>> doesn't preclude interested people from enhancing the existing
> notebook in
> >>> the short term.  We'd like the phosphor notebook to get to a comparable
> >>> state with the current notebook as quickly as possible, but it will
> still
> >>> take some time.
> >>>
> >>> Also, I totally agree with Thomas that dogfooding the notebook (and
> >>> watching/helping others actually use it to get work done) is
> *extremely*
> >>> important to understanding what we want here.  And I also agree with
> others
> >>> on this thread that documentation is sorely lacking.  We'll be working
> on
> >>> that in the phosphor notebook as we go along too.
> >>>
> >>> Thanks,
> >>>
> >>> Jason
> >>>
> >>> _______________________________________________
> >>> IPython-dev mailing list
> >>> IPython-dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>
> >>
> >>
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> 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/20150629/4ce7ec3d/attachment.html>