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

[MinRK]

I think user fridays, or something similar is a great idea. We tend to do
our best work when we are *using* IPython most (I found a couple things to
fix while teaching  this week).  I also think stabilizing and focusing on
user features for a while is a good plan, and I think we can do that in
many parts of IPython/Jupyter (remember, there isn't going to be a single
IPython/Jupyter 5.0). Unfortunately, I think the client-side of the
notebook is not a place where we can afford to do that right now. I think
we need to almost start from scratch with that stuff notebook, in order to
enable the things we want to do with it.

Technically, we could do both:

- create a 5.0 branch, where we start over with typescript/phosphor
- continue to work on 4.1, 4.2, where we add these user-facing features
with the code in the state that it is.

This is actually one way that we can get more people working on the
notebook - some people working on features in 4.1, 4.2, while the 5.x
restructuring is going on. We don't need to follow the backports-only
pattern for minor releases we have done for IPython recently, which we do
in part due to our relative lack of developer time. In some ways, we are
coming into the opposite problem - too many people, not enough available
parallel work. I'm not saying it's necessarily what we should do, but it is
an option available.

-MinRK

On Sat, Jun 27, 2015 at 10:55 AM, Matthias Bussonnier <
bussonniermatthias at gmail.com> wrote:

> Hi All,
>
> Thanks for doing this on the public Mailing list, it seem we are improving
> our communication skills,
> be careful though, the response start to have more and more implicit
> knowledge.
>
> I do hear what Thomas is saying too, but I have seen to numerous time
> people reimplementing
> in javascript pieces of our codes because they are un-reusable (hydrogen,
> notable mind, the
> things that render notebook purely in js ... ) so it seem that **some**
> refactoring is needed.
>
> I’m not really happy to have done the conversion to typescript without API
> changes,
> and not got my PRs merged, and it seemed like these last month any changes
> to
> the notebook has had a strong pushback. And without theses changes we
> basically
> won’t have any new features. That seem (to me) like a pretty stable
> javascript Api
> for something we said can change at any time as we **want** to refactor.
>
> Writing some of our SciPy tutorial also made me realize how some low level
> feature
> of the notebook API (I know, not stable) are broken in design, and
> hopefully not used to much.
>
> So I really hope we clean things.
>
>
> That being said, I would also really like to spend more time **using** the
> notebook,
> to do "user Friday’  and show really cool things that can be done. Though
> I think it is something
> which is hard to do with the current technical dept.
>
> --
> M
>
>
> > On Jun 27, 2015, at 08:30, Brian Granger <ellisonbg at gmail.com> wrote:
> >
> >> What's going to be very challenging in this effort is the *coordination*
> >> part.  We need to make sure that we have both a chance for proper
> discussion
> >> of the key ideas, and for open coordination of the effort while it's
> >> happening, so that:
> >
> > Yep, I definitely agree that the coordination, organizational and
> > communication aspects of the project will have to evolve in parallel
> > to the code base.
> >
> >>
> >> a) whoever ends up working on the critical path can focus on that and
> just
> >> get the nasty business done
> >>
> >> b) the rest of the team can feel comfortable that there's still other
> areas
> >> where work can proceed cleanly and without interference or blockage.
> >
> > My hope is that with the right technical choices and coordination,
> > that we can remove the critical paths altogether. I have ideas on how
> > to pull this off, and will post separately to the list about that.
> >
> >> It would be great if during scipy, you folks try to draft an outline of
> what
> >> the key pieces of that refactoring would entail, identifying what areas
> of
> >> the project would effectively hold locks. That would let us more easily
> >> define what is NOT locked, so we can then partition things for everyone
> else
> >> to work on.
> >
> > Yes, I think that should be one of the main goals. But I want the
> > discussion to be focused on *how* we do this, not *if*.
> >
> >>
> >> Let's have that publicly documented (probably as an IPEP) so that we
> don't
> >> break the team in the process...
> >
> > Yep!
> >
> > Cheers,
> >
> > Brian
> >
> >>
> >> Cheers
> >>
> >> f
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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/20150628/1d972003/attachment.html>