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

[Jonathan Frederic]

>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150629/8bd3c955/attachment.html>