Proposal: soft moratorium on re-architecting for 5.0

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Proposal: soft moratorium on re-architecting for 5.0

Thomas Kluyver-2
I'd like to float the idea of a soft moratorium on big architectural changes in the notebook between 4.0 and 5.0. That is, as 4.0 will mostly be 3.x's features on a new foundation, 5.0 would be mostly the 4.0's foundations with added & polished features.

With 4.0, we'll have made two consecutive major releases where the headline changes are architectural: the kernelspec machinery and changes for language agnosticity in 3.0, and the Big Split in 4.0. We've done all of this for good reasons, but I worry that we're becoming captivated by the endless programmer dream of creating the perfect framework to solve all our problems.

One of the principles to which we attribute the success of the project so far is that we solve the problems in front of us and restructure when we need to, rather than rushing into building grand architecture. I think that we need a cycle to digest the architectural changes we've recently made before we dive into another round. In particular, the talk of refactoring all our frontend machinery concerns me. I don't want to stop us from planning this, but I think it would be a mistake to try to do it for 5.0.

There are a lot of important features that we have been saying for some time we will work on - like multi cell selection, find & replace across the notebook, improved tab completion, and an HTML console interface. We've deferred these tasks while we worked on the architecture, and it's starting to be embarrassing that the interface is not moving forwards quicker. There would also be less impetus for people to turn to competing projects if we sanded some of the rough edges off the notebook interface.

On that note, I'd like us to try doing 'user Fridays', where we pretend that we can't change the Jupyter/IPython code, and work on making interesting notebooks, extensions, and other parts of the ecosystem. Every time I work on such things, it highlights problems I wasn't aware of, or rough edges I hadn't fully appreciated. Having a semi-official mechanism to encourage us to do this in regular small chunks would be valuable in keeping us focussed on users rather than just architecture.

The moratorium I propose would be left to our judgement to implement - it's a principle rather than a rule. I'd make an exception for the conversion to Typescript, because Matthias has already spent significant time on that, and I know he's champing at the bit to finish it. Widgets would be exempt, because we've made it very clear that they're liable to change significantly, and they shouldn't much affect development of the notebook itself.

Thanks,
Thomas

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Fernando Perez

On Fri, Jun 26, 2015 at 4:09 PM, Thomas Kluyver <[hidden email]> wrote:
The moratorium I propose would be left to our judgement to implement - it's a principle rather than a rule. I'd make an exception for the conversion to Typescript, because Matthias has already spent significant time on that, and I know he's champing at the bit to finish it. Widgets would be exempt, because we've made it very clear that they're liable to change significantly, and they shouldn't much affect development of the notebook itself.

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

and this is part of the reason why Matthias has been working on the Typescript conversion, and also one of the big bottleneck points: we know that multiple folks want to customize the notebook UI more heavily, and in its current incarnation, that's very, very difficult. And for multiple teams working in different directions, probably impractical/impossible at the end of the day.

The current Notebook is, in a certain sense, where the core IPython code was sometime in the 0.9-0.10 period: highly functional, yet highly monolithic and very difficult to change, adapt or extend.  And I really think that, just as much as eventually we had to bite that bullet, and how we benefitted from doing so at the time, we have to do the UI restructuring now.

I really don't see how, right now, multiple folks are going to be able to simultaneously work on the notebook codebase being as monolithic as it is.

So yes, I do hear you, and I think it's important that we don't lose sight of the value for our users.  We can't become a project that only looks at its own development needs and never produces features that actually matter to its users.  That's more or less what Python did with Python 3, and we all know how that went...

But I do think that we've accrued sufficient technical debt with the codebase of the notebook, and we have enough pressure *already at our doorstep* from multiple fronts regarding the need to implement many different types of tools and ideas atop the web frontend, that we need to open that up.  

What I hope is that over the next few days at Scipy, when most of you (sadly without me) have a chance to meet face to face, you'll be able to hatch a plan to do this in a way that doesn't lose track of the important goals:

- do a minimal refactoring that preserves today's functionality, even if there's perhaps a small loss in polish on first release.

- get a more decoupled codebase that will allow us to build the various pieces we need.

But I honestly don't see the current notebook codebase supporting the pressure we have already on it without a refactoring right away, precisely so that we can let more folks build new functionality...

Cheers,

f

--
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Chris Colbert
I have to side firmly with Fernando on this one. After ripping apart the notebook code base over the last few days, it's become clear that things need change measurably if we are going to move forward with a platform that is both maintainable and customizable.  There is quite a bit of technical debt in there, and that bill is coming due. My team and cohorts are ready, willing, and able to tackle this problem (as Fernando mentioned, we've already started), and I think it would be a strategic mistake to shut the door on the momentum we've been building over the last several months.

On Fri, Jun 26, 2015 at 7:45 PM, Fernando Perez <[hidden email]> wrote:

On Fri, Jun 26, 2015 at 4:09 PM, Thomas Kluyver <[hidden email]> wrote:
The moratorium I propose would be left to our judgement to implement - it's a principle rather than a rule. I'd make an exception for the conversion to Typescript, because Matthias has already spent significant time on that, and I know he's champing at the bit to finish it. Widgets would be exempt, because we've made it very clear that they're liable to change significantly, and they shouldn't much affect development of the notebook itself.

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

and this is part of the reason why Matthias has been working on the Typescript conversion, and also one of the big bottleneck points: we know that multiple folks want to customize the notebook UI more heavily, and in its current incarnation, that's very, very difficult. And for multiple teams working in different directions, probably impractical/impossible at the end of the day.

The current Notebook is, in a certain sense, where the core IPython code was sometime in the 0.9-0.10 period: highly functional, yet highly monolithic and very difficult to change, adapt or extend.  And I really think that, just as much as eventually we had to bite that bullet, and how we benefitted from doing so at the time, we have to do the UI restructuring now.

I really don't see how, right now, multiple folks are going to be able to simultaneously work on the notebook codebase being as monolithic as it is.

So yes, I do hear you, and I think it's important that we don't lose sight of the value for our users.  We can't become a project that only looks at its own development needs and never produces features that actually matter to its users.  That's more or less what Python did with Python 3, and we all know how that went...

But I do think that we've accrued sufficient technical debt with the codebase of the notebook, and we have enough pressure *already at our doorstep* from multiple fronts regarding the need to implement many different types of tools and ideas atop the web frontend, that we need to open that up.  

What I hope is that over the next few days at Scipy, when most of you (sadly without me) have a chance to meet face to face, you'll be able to hatch a plan to do this in a way that doesn't lose track of the important goals:

- do a minimal refactoring that preserves today's functionality, even if there's perhaps a small loss in polish on first release.

- get a more decoupled codebase that will allow us to build the various pieces we need.

But I honestly don't see the current notebook codebase supporting the pressure we have already on it without a refactoring right away, precisely so that we can let more folks build new functionality...

Cheers,

f

--
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Fernando Perez
On Fri, Jun 26, 2015 at 5:38 PM, Chris Colbert <[hidden email]> wrote:
I have to side firmly with Fernando on this one. After ripping apart the notebook code base over the last few days, it's become clear that things need change measurably if we are going to move forward with a platform that is both maintainable and customizable.  There is quite a bit of technical debt in there, and that bill is coming due. My team and cohorts are ready, willing, and able to tackle this problem (as Fernando mentioned, we've already started), and I think it would be a strategic mistake to shut the door on the momentum we've been building over the last several months.

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:

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.

In the past we've been reasonably good at these kinds of things, but the project is getting bigger, more complicated, and we have more people too. So the challenge this time is going to be significantly harder.  Let's put in the necessary effort also into communicating how to do this right, so we come out ahead with a cleaner codebase we're all happier working on in short order...

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.

Let's have that publicly documented (probably as an IPEP) so that we don't break the team in the process...

Cheers

f

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Brian Granger-3
In reply to this post by Thomas Kluyver-2
> One of the principles to which we attribute the success of the project so
> far is that we solve the problems in front of us and restructure when we
> need to, rather than rushing into building grand architecture. I think that
> we need a cycle to digest the architectural changes we've recently made
> before we dive into another round. In particular, the talk of refactoring
> all our frontend machinery concerns me. I don't want to stop us from
> planning this, but I think it would be a mistake to try to do it for 5.0.

I do think there are part of our code base where conservatism is
useful and beneficial: the message specification, notebook document
format, kernel spec, etc. Many features and APIs associated with the
ipython kernel are also evolving in a pretty conservative manner. The
server side of the notebook is reasonably stable, although the
real-time collab and ongoing security efforts will require significant
changes to parts of it.

However, I think the project would be deeply hurt by applying this
conservatism broadly or to the notebook frontend in particular.

>
> There are a lot of important features that we have been saying for some time
> we will work on - like multi cell selection, find & replace across the
> notebook, improved tab completion, and an HTML console interface. We've
> deferred these tasks while we worked on the architecture, and it's starting
> to be embarrassing that the interface is not moving forwards quicker. There
> would also be less impetus for people to turn to competing projects if we
> sanded some of the rough edges off the notebook interface.

I agree that we have lots of rough edge that are adversely affecting
our users today. These range from bugs, usability problems, basic
features that are lacking, and new, highly-anticipated features.
However, the development challenges we have seen in trying to
implement these things strongly point to continuing with a deep
architectural surgery:

* Off the top of my head, between Cal Poly, Berkeley, Google,
Bloomberg and Continuum I can count 8-ish existing staff being
allocated to work full time on the notebook. With upcoming new hires
at Cal Poly and Berkeley, this number will go over >10 staff working
primarily on the notebook.
* Our existing monolithic, tightly-coupled frontend code makes it
impossible for more than 1-2 main lines of frontend work to move
forward at the same time.
* We have numerous third part projects and companies (kbase, Rodeo,
Hydrogen, Sage, IBM, Quantopian, DataRobot, O'Reilly, etc.) who are
taking our frontend code and using it to build customized frontend
applications. Our code base is making this extremely difficult for
these groups. Because of this, each of these groups is having to
maintain and develop forks, rather than working with us to build a
common set of flexible components. This means that everyone is
resolving the same problems in ways that our users don't benefit from.

Deep changes in the frontend code are needed, precisely because there
is no way we can build the user-focused features with this many people
using our currently code base. Even something like the HTML console
interface will be dramatically easier - if not trivial - once the code
base is refactored into better-designed, loosely coupled components.

> On that note, I'd like us to try doing 'user Fridays', where we pretend that
> we can't change the Jupyter/IPython code, and work on making interesting
> notebooks, extensions, and other parts of the ecosystem. Every time I work
> on such things, it highlights problems I wasn't aware of, or rough edges I
> hadn't fully appreciated. Having a semi-official mechanism to encourage us
> to do this in regular small chunks would be valuable in keeping us focussed
> on users rather than just architecture.

I agree this is useful for all of us to do on a continual basis. I
just finished teaching for ten weeks and most of my time was spent in
doing this type of stuff. It was wonderful and very instructive.

> The moratorium I propose would be left to our judgement to implement - it's
> a principle rather than a rule. I'd make an exception for the conversion to
> Typescript, because Matthias has already spent significant time on that, and
> I know he's champing at the bit to finish it. Widgets would be exempt,
> because we've made it very clear that they're liable to change
> significantly, and they shouldn't much affect development of the notebook
> itself.
>
> Thanks,
> Thomas
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[hidden email] and [hidden email]
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Brian Granger-3
In reply to this post by Fernando Perez
> 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
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[hidden email] and [hidden email]
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Wes Turner
In reply to this post by Brian Granger-3


On Jun 27, 2015 1:26 AM, "Brian Granger" <[hidden email]> wrote:
>
> > One of the principles to which we attribute the success of the project so
> > far is that we solve the problems in front of us and restructure when we
> > need to, rather than rushing into building grand architecture. I think that
> > we need a cycle to digest the architectural changes we've recently made
> > before we dive into another round. In particular, the talk of refactoring
> > all our frontend machinery concerns me. I don't want to stop us from
> > planning this, but I think it would be a mistake to try to do it for 5.0.
>
> I do think there are part of our code base where conservatism is
> useful and beneficial: the message specification, notebook document
> format, kernel spec, etc. Many features and APIs associated with the
> ipython kernel are also evolving in a pretty conservative manner. The
> server side of the notebook is reasonably stable, although the
> real-time collab and ongoing security efforts will require significant
> changes to parts of it.
>
> However, I think the project would be deeply hurt by applying this
> conservatism broadly or to the notebook frontend in particular.
>
> >
> > There are a lot of important features that we have been saying for some time
> > we will work on - like multi cell selection, find & replace across the
> > notebook, improved tab completion, and an HTML console interface. We've
> > deferred these tasks while we worked on the architecture, and it's starting
> > to be embarrassing that the interface is not moving forwards quicker. There
> > would also be less impetus for people to turn to competing projects if we
> > sanded some of the rough edges off the notebook interface.
>
> I agree that we have lots of rough edge that are adversely affecting
> our users today. These range from bugs, usability problems, basic
> features that are lacking, and new, highly-anticipated features.
> However, the development challenges we have seen in trying to
> implement these things strongly point to continuing with a deep
> architectural surgery:
>
> * Off the top of my head, between Cal Poly, Berkeley, Google,
> Bloomberg and Continuum I can count 8-ish existing staff being
> allocated to work full time on the notebook. With upcoming new hires
> at Cal Poly and Berkeley, this number will go over >10 staff working
> primarily on the notebook.
> * Our existing monolithic, tightly-coupled frontend code makes it
> impossible for more than 1-2 main lines of frontend work to move
> forward at the same time.
> * We have numerous third part projects and companies (kbase, Rodeo,
> Hydrogen, Sage, IBM, Quantopian, DataRobot, O'Reilly, etc.) who are
> taking our frontend code and using it to build customized frontend
> applications. Our code base is making this extremely difficult for
> these groups. Because of this, each of these groups is having to
> maintain and develop forks, rather than working with us to build a
> common set of flexible components. This means that everyone is
> resolving the same problems in ways that our users don't benefit from.
>
> Deep changes in the frontend code are needed, precisely because there
> is no way we can build the user-focused features with this many people
> using our currently code base. Even something like the HTML console
> interface will be dramatically easier - if not trivial - once the code
> base is refactored into better-designed, loosely coupled components.

I'm impressed by the notablemind react components: https://github.com/notablemind/notablemind/tree/master/app/components

These seem to solve for the non-ot.js real-time parts as well. (See: etherpad-lite, apache wave protocol).

>
> > On that note, I'd like us to try doing 'user Fridays', where we pretend that
> > we can't change the Jupyter/IPython code, and work on making interesting
> > notebooks, extensions, and other parts of the ecosystem. Every time I work
> > on such things, it highlights problems I wasn't aware of, or rough edges I
> > hadn't fully appreciated. Having a semi-official mechanism to encourage us
> > to do this in regular small chunks would be valuable in keeping us focussed
> > on users rather than just architecture.
>
> I agree this is useful for all of us to do on a continual basis. I
> just finished teaching for ten weeks and most of my time was spent in
> doing this type of stuff. It was wonderful and very instructive.
>
> > The moratorium I propose would be left to our judgement to implement - it's
> > a principle rather than a rule. I'd make an exception for the conversion to
> > Typescript, because Matthias has already spent significant time on that, and
> > I know he's champing at the bit to finish it. Widgets would be exempt,
> > because we've made it very clear that they're liable to change
> > significantly, and they shouldn't much affect development of the notebook
> > itself.
> >
> > Thanks,
> > Thomas
> >
> > _______________________________________________
> > IPython-dev mailing list
> > [hidden email]
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> [hidden email] and [hidden email]
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Matthias Bussonnier
In reply to this post by Brian Granger-3
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 <[hidden email]> 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
>> [hidden email]
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> [hidden email] and [hidden email]
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Fernando Perez

On Sat, Jun 27, 2015 at 2:55 AM, Matthias Bussonnier <[hidden email]> wrote:
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.

Yes, I really think we have no option but work on this...

There's one word that keeps me up at night right now when I think of this: MySpace...

Basically, we've established a lot of early momentum in the space of the notebook, our interactive kernel architecture, etc. But in doing so, we've actually shown the value of the problem space to be so important, that lots and lots of other players are now moving in, and many of them need to build new ideas rapidly.

Fortunately for us, some of them are actually willing to work with us to refactor our machinery to enable a far better set of tools to be built in the near future atop of our same overall design.   But unless we actually do that, most folks would eventually just decide to simply do something else and build elsewhere...

So, let's try to not end up like MySpace.  The refactoring work is really critical, and it's work we *can* do in a relatively limited timeframe. It won't be trivial, but it won't take a year either.  With some careful planning and dedicated effort, we can pull through in a few months and have a cleaner foundation to build upon.

Cheers

f


--
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Fernando Perez
Here's an email that Andrew sent me privately, but with his authorization, I'm replying to it on the public list as I think his concerns have a lot of merit and I'm sure others would be interested in the topic as well...


On Fri, Jun 26, 2015 at 9:56 PM, Andrew Gibiansky <[hidden email]> wrote:
Fernando,

However, I would like to urge you and the IPython team to consider focusing a little bit of effort towards something that has gone unmentioned: documentation.

The IPython documentation has suffered from a few main problems:
  • It is often out of date. The messaging spec that was accessible, as of a few weeks ago, was out of date and simply wrong about some things in IPython 3.1.
  • Significant portions are undocumented, or documented only through their original IPEPs. For example, the backbone widgets! I am currently working with a student for GSOC to implement widget support for IHaskell, and he regularly has to resort to spelunking through the IPython source to implement the same functionality, rather than looking at a spec.
  • Finally, and most importantly, the frontend is completely undocumented. As far as I can tell, the suggested way towards developing anything for the frontend is to grep through the source code, for example for which events are available to be bound to. The result of this is that developing frontend custom.js or extensions is nigh impossible; even simple ones become a gargantuan task requiring you to delve deep into IPython JS source code, and more extensive extensions can only be done by core IPython contributors (or people with similarly deep knowledge). As someone who is very familiar with IPython (having written IHaskell and a few frontend extensions and customizations), it is very difficult even for me to get anything done on the frontend, much less someone with less experience. I believe this significantly hinders development of new extensions, widgets, and frontends.
Seeing Thomas' suggestion, I think it would be really great if the team could tackle the occasionally poor documentation right now. (I say 'occasionally' because the documentation is still much much better than many other projects!) From an external standpoint, it seems like the amount of technical debt in IPython is growing somewhat unmanageable to deal with for an outsider, in part because of the lack of documentation. Even if now is not the right time for a focus on documentation, it would be wonderful if this were brought up and if perhaps it were scoped out as part of the schedule for the upcoming months.

Again, please take this in the best way possible – this is not meant as criticism of the way IPython is being developed but rather as an expression of what would be important to me, a very frequent user of IPython and developer of a fairly popular backend. With all of this in mind, I want to say that I'm incredibly impressed with the quality and pace of development, and it's exciting to see plans for 4.0 and 5.0 being made!

These concerns are absolutely spot-on, and we're painfully aware of the impact that the rather sad state of our docs has on users and developers of the system alike.  Furthermore, we know that it creates a significant barrier to entry to new contributions, and to growing a healthier community of participation around the project.

We have, sadly, dug a pretty deep hole here, and it will take some real effort to climb back out of it, so this isn't going to happen overnight.

We've been, over the last few months, working very hard on trying to secure some resources to ensure that the core team can remain employed, which is an even more critical concern for some of us, as I hope you'll understand :)

We hope to have some good news to report on that front before too long, and once we can get some proper resources in place, we actually will put documentation efforts as a first-class priority.  Even before that, we have a few small steps in the right direction:

- Min went this spring to the WriteTheDocs conference, to start meeting technical writers and get a bit more acquainted with that community, 

- Brian has already hired some new summer students who are starting to improve the layout of the websites.  That's not the same as writing a bunch of new docs, but having better websites will help.  The PRs are here: https://github.com/jupyter/design/issues/15https://github.com/jupyter/design/issues/16, help always welcome.

- We've actually already started work on restructuring all the repos for better docs, and I know that Thomas, Brian, Jess, Jon, Matthias and others (sorry folks for whoever I'm not crediting directly) have put work into it.   At least now we have an overall skeleton so that the navigation of the docs for the overall project is more comprehensible:


and we're also working on tooling to smooth the integration of notebooks into the sphinx workflow.


These efforts are all partial, and cooking at slow simmer because people are more or less at max capacity trying to get 4.0 out the door and with the Scipy conference breathing down our necks.

I would say though that, once 4.0 is out the door, with this new skeleton in place, contributing docs will be a place where the community can *definitely* help the project.  I know until now it was hard to even help with documentation, because the layout of our docs was so messy and monolithic.  We're trying to precisely help with making it easier to *contribute*, please let us know if this new structure looks like a step in the right direction or not...


But we are not, not at all, ignoring your concerns. Hopefully in a few days/weeks we'll have a bit more we can share on that front that will help too...

Cheers,

f

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

MinRK
In reply to this post by Matthias Bussonnier
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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> [hidden email] and [hidden email]
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Nicholas Bollweg
In reply to this post by Fernando Perez

Wow, go away for a weekend and all hell breaks loose! Really good stuff here.

+1 to docs living in notebooks, and using as their primary presentation, the notebook ui.

When authoring a notebook, what if a user didn't have to leave the ui to go search five websites to find out a) what a particular class does and b) what other classes do that?

For why, see the Mathematica documentation, which is really a better yardstick than other open source projects.

We already maintain and ship to every user a sophisticated document management platform, the benefits of which are mostly destroyed when serialized to static html. Mix in indexed search, and wiki-style "what links here", and we've got something really powerful. If sphinx plays a role in exposing source files as notebooks, so much the better, but Mathematica, for example, has the burden of documenting everything for users in prose/signatures. I'm sure their developers write beautiful source for each other, as the platform is now something like 30 years old.... Can't be much debt left, right?

Bringing in another thread, typescript will give us the descriptive power to provide deep, linked data links to browser code, and improve browser-side documentation generally. Phosphor then also has the ui abstracting power to make an in browser documentation viewer unsurprising.

Additionally, kernel authors, kernel-agnostic nbextenders and such would then have a compelling reason to author, ship and maintain notebooks... A hook here and there, and you are indexed along with everything else.

Something like ipymd could close the vcs maintainability gap (once it has metadata), while nosebook (once it does coverage, and in addition to other tests) could close the loop, making the shipping of uncovered/undocumented code a much more intentional act.

Excited for more discussion!


On 06:55, Mon, Jun 29, 2015 Fernando Perez <[hidden email]> wrote:
Here's an email that Andrew sent me privately, but with his authorization, I'm replying to it on the public list as I think his concerns have a lot of merit and I'm sure others would be interested in the topic as well...


On Fri, Jun 26, 2015 at 9:56 PM, Andrew Gibiansky <[hidden email]> wrote:
Fernando,

However, I would like to urge you and the IPython team to consider focusing a little bit of effort towards something that has gone unmentioned: documentation.

The IPython documentation has suffered from a few main problems:
  • It is often out of date. The messaging spec that was accessible, as of a few weeks ago, was out of date and simply wrong about some things in IPython 3.1.
  • Significant portions are undocumented, or documented only through their original IPEPs. For example, the backbone widgets! I am currently working with a student for GSOC to implement widget support for IHaskell, and he regularly has to resort to spelunking through the IPython source to implement the same functionality, rather than looking at a spec.
  • Finally, and most importantly, the frontend is completely undocumented. As far as I can tell, the suggested way towards developing anything for the frontend is to grep through the source code, for example for which events are available to be bound to. The result of this is that developing frontend custom.js or extensions is nigh impossible; even simple ones become a gargantuan task requiring you to delve deep into IPython JS source code, and more extensive extensions can only be done by core IPython contributors (or people with similarly deep knowledge). As someone who is very familiar with IPython (having written IHaskell and a few frontend extensions and customizations), it is very difficult even for me to get anything done on the frontend, much less someone with less experience. I believe this significantly hinders development of new extensions, widgets, and frontends.
Seeing Thomas' suggestion, I think it would be really great if the team could tackle the occasionally poor documentation right now. (I say 'occasionally' because the documentation is still much much better than many other projects!) From an external standpoint, it seems like the amount of technical debt in IPython is growing somewhat unmanageable to deal with for an outsider, in part because of the lack of documentation. Even if now is not the right time for a focus on documentation, it would be wonderful if this were brought up and if perhaps it were scoped out as part of the schedule for the upcoming months.

Again, please take this in the best way possible – this is not meant as criticism of the way IPython is being developed but rather as an expression of what would be important to me, a very frequent user of IPython and developer of a fairly popular backend. With all of this in mind, I want to say that I'm incredibly impressed with the quality and pace of development, and it's exciting to see plans for 4.0 and 5.0 being made!

These concerns are absolutely spot-on, and we're painfully aware of the impact that the rather sad state of our docs has on users and developers of the system alike.  Furthermore, we know that it creates a significant barrier to entry to new contributions, and to growing a healthier community of participation around the project.

We have, sadly, dug a pretty deep hole here, and it will take some real effort to climb back out of it, so this isn't going to happen overnight.

We've been, over the last few months, working very hard on trying to secure some resources to ensure that the core team can remain employed, which is an even more critical concern for some of us, as I hope you'll understand :)

We hope to have some good news to report on that front before too long, and once we can get some proper resources in place, we actually will put documentation efforts as a first-class priority.  Even before that, we have a few small steps in the right direction:

- Min went this spring to the WriteTheDocs conference, to start meeting technical writers and get a bit more acquainted with that community, 

- Brian has already hired some new summer students who are starting to improve the layout of the websites.  That's not the same as writing a bunch of new docs, but having better websites will help.  The PRs are here: https://github.com/jupyter/design/issues/15https://github.com/jupyter/design/issues/16, help always welcome.

- We've actually already started work on restructuring all the repos for better docs, and I know that Thomas, Brian, Jess, Jon, Matthias and others (sorry folks for whoever I'm not crediting directly) have put work into it.   At least now we have an overall skeleton so that the navigation of the docs for the overall project is more comprehensible:


and we're also working on tooling to smooth the integration of notebooks into the sphinx workflow.


These efforts are all partial, and cooking at slow simmer because people are more or less at max capacity trying to get 4.0 out the door and with the Scipy conference breathing down our necks.

I would say though that, once 4.0 is out the door, with this new skeleton in place, contributing docs will be a place where the community can *definitely* help the project.  I know until now it was hard to even help with documentation, because the layout of our docs was so messy and monolithic.  We're trying to precisely help with making it easier to *contribute*, please let us know if this new structure looks like a step in the right direction or not...


But we are not, not at all, ignoring your concerns. Hopefully in a few days/weeks we'll have a bit more we can share on that front that will help too...

Cheers,

f
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Jason Grout
In reply to this post by Fernando Perez
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
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Matthias Bussonnier

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.

Done, Jason you are admin, I **think** you can all people to the team. 
I’m hopping on my plane, like in 5 min. Feeling like Linus writing a rc release not from airports as often. 
(I haven’t forked your to make sure it appears as a root repo) 


Quick +1 on typescript the type aliases allow you to so 

define Path extends String {}

Which auto produce nice docs  with meaning instead of just foo(a:string, a:string) you get foo(a:Path, b:NotebookName)
which is really good for docs.


See you Tuesday morning on dev meeting, which for once should **not** be public, as we are trying BlueJeans. 
-- 
M


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
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Kyle Kelley
Gosh, I'd rather read foo(path:string, notebookName:string) any day, instead of having to *also* reference aliases infer based on the name itself.

On Mon, Jun 29, 2015 at 8:43 AM, Matthias Bussonnier <[hidden email]> wrote:

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.

Done, Jason you are admin, I **think** you can all people to the team. 
I’m hopping on my plane, like in 5 min. Feeling like Linus writing a rc release not from airports as often. 
(I haven’t forked your to make sure it appears as a root repo) 


Quick +1 on typescript the type aliases allow you to so 

define Path extends String {}

Which auto produce nice docs  with meaning instead of just foo(a:string, a:string) you get foo(a:Path, b:NotebookName)
which is really good for docs.


See you Tuesday morning on dev meeting, which for once should **not** be public, as we are trying BlueJeans. 
-- 
M


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
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev




--

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Sylvain Corlay
In reply to this post by Jason Grout
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 <[hidden email]> 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
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Brian Granger-3
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.

On Mon, Jun 29, 2015 at 10:54 AM, Jonathan Frederic
<[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> [hidden email]
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[hidden email] and [hidden email]
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

MinRK


On Mon, Jun 29, 2015 at 11:15 AM, Brian Granger <[hidden email]> 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
<[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> [hidden email]
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[hidden email] and [hidden email]
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: soft moratorium on re-architecting for 5.0

Wes Turner
In reply to this post by Brian Granger-3
With the HubFlow (GitFlow) branch structure, I think this would look something like:

- master (lastest tagged stable release)
- develop (stable trunk)
- feature
  - feature/phosphor (rebase -i develop)
- hotfix/ (-> master, -> develop)
  - hotfix/docs
- release/


.. index:: HubFlow
.. _hubflow:

HubFlow
~~~~~~~~~
| Src: https://github.com/datasift/gitflow
| Docs: https://datasift.github.io/gitflow/
| Docs: https://datasift.github.io/gitflow/IntroducingGitFlow.html
| Docs: https://datasift.github.io/gitflow/TheHubFlowTools.html

HubFlow is a fork of GitFlow
that adds extremely useful commands for working with Git and GitHub.

HubFlow is a named branch workflow with mostly-automated merges
between branches.

Branch names are configurable; the defaults are as follows:


+--------------------+-------------------------------------------------------------------------+
| **Branch Name**    | **Description**                                                         |
|                    | (and `Code Labels <https://westurner.org/wiki/workflow#code-labels>`__) |
+--------------------+-------------------------------------------------------------------------+
| ``master``         | Stable trunk (latest release)                                           |
+--------------------+-------------------------------------------------------------------------+
| ``develop``        | Development main line                                                   |
+--------------------+-------------------------------------------------------------------------+
| ``feature/<name>`` | New features for the next release (e.g. ``ENH``, ``PRF``)               |
+--------------------+-------------------------------------------------------------------------+
| ``hotfix/<name>``  | Fixes to merge to both ``master`` and ``develop``                       |
|                    | (e.g. ``BUG``, ``TST``, ``DOC``)                                        |
+--------------------+-------------------------------------------------------------------------+
| ``release/<name>`` | In-progress release branches (e.g. ``RLS``)                             |
+--------------------+-------------------------------------------------------------------------+

Creating a new release with :ref:`Git` and HubFlow:

.. code:: bash

  git clone ssh://git@.../westurner/dotfiles
  # git checkout master
  git hf init
  ## Update versiontag in .git/config to prefix release tags with 'v'
  git config hubflow.prefix.versiontag=v
  #cat .git/config # ...
  # [hubflow "prefix"]
  # feature = feature/
  # release = release/
  # hotfix = hotfix/
  # support = support/
  # versiontag = v
  #
  git hf feature start ENH_print_hello_world
  ## commit, commit, commit
  git hf feature finish ENH_print_hello_world   # ENH<TAB>
  git hf release start 0.1.0
  ## commit (e.g. update __version__, setup.py, release notes)
  git hf release finish 0.1.0
  git hf release finish 0.1.0
  git tag | grep 'v0.1.0'

The GitFlow HubFlow illustrations are very helpful for visualizing
and understanding any DVCS workflow:
`<https://datasift.github.io/gitflow/IntroducingGitFlow.html>`__.

****** with HTML formatting *****

git clone ssh://git@.../westurner/dotfiles
# git checkout master
git hf init
## Update versiontag in .git/config to prefix release tags with 'v'
git config hubflow.prefix.versiontag=v
#cat .git/config # ...
# [hubflow "prefix"]
# feature = feature/
# release = release/
# hotfix = hotfix/
# support = support/
# versiontag = v
#
git hf feature start ENH_print_hello_world
## commit, commit, commit
git hf feature finish ENH_print_hello_world   # ENH<TAB>
git hf release start 0.1.0
## commit (e.g. update __version__, setup.py, release notes)
git hf release finish 0.1.0
git hf release finish 0.1.0
git tag | grep 'v0.1.0'

On Mon, Jun 29, 2015 at 1:15 PM, Brian Granger <[hidden email]> 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.

On Mon, Jun 29, 2015 at 10:54 AM, Jonathan Frederic
<[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> [hidden email]
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[hidden email] and [hidden email]
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
123