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

[Matthias Bussonnier]

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