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

Brian Granger ellisonbg at gmail.com
Mon Jun 29 14:35:18 EDT 2015


Good points - I guess with the magnitude of the changes that are going
to be happening with the notebook and widget it would be nice to have
a working master. +1 then to the 5.0 brance idea for those repos.

On Mon, Jun 29, 2015 at 11:33 AM, Wes Turner <wes.turner at gmail.com> wrote:
>
>
> On Mon, Jun 29, 2015 at 1:23 PM, MinRK <benjaminrk at gmail.com> wrote:
>>
>>
>>
>> On Mon, Jun 29, 2015 at 11:15 AM, Brian Granger <ellisonbg at gmail.com>
>> wrote:
>>>
>>> I am +1 on having separate branches for ongoing 4.x work that include
>>> more than just bug fixes - especially for the notebook and widgets. I
>>> have a slight preference to have master always be the newer stuff, but
>>> don't feel too strongly about that.
>>
>>
>> I think there's typically a transition point. For instance, we had
>> long-running experiment/dev branches for kernel/qtconsole, notebook, and
>> zmq-based IPython.parallel that weren't master. I think once these things
>> become "good enough" they can hop over to master, and the minor-release
>> branches can be bumped. We typically try to live in a "master always works"
>> state, and some of these things can take a while to get there, in which case
>> a feature branch is appropriate for the early stages of development. They
>> can then become master once ready for "primetime", which is to say that we
>> expect most IPython/Jupyter devs to be using it by default. But in general,
>> I agree that master == newer stuff, as long as it's usable.
>
>
> I think there's a really strong argument for having stable master, tests
> passing on develop always,
> and separate branches.
>
> As a novice, when I 'git clone https://github.com/ipython/ipython',
> I sort of expect a passing build
> (preferably the latest tagged release; as with, again, sorry, HubFlow).
>
> With HubFlow, branch names are configurable: This is from a HubFlow
> .git/config:
>
> [hubflow "branch"]
> master = master
> develop = develop
>
> [hubflow "prefix"]
> feature = feature/
> release = release/
> hotfix = hotfix/
> support = support/
> versiontag = v
>
>>
>>
>> -MinRK
>>
>>>
>>>
>>> On Mon, Jun 29, 2015 at 10:54 AM, Jonathan Frederic
>>> <jon.freder at gmail.com> wrote:
>>> >> I wanted to +1 the proposal to start creating branches for new
>>> >> versions
>>> >> when a feature freeze occurs.
>>> >
>>> >
>>> > +1 here too, I'm going to do that with ipywidgets for SciPy, create a
>>> > 5.x
>>> > branch.  There's a lot of stuff I want to get a jump start on, and
>>> > SciPy is
>>> > a great time to do it.  I don't want it to end up like numerous other
>>> > experiments, which end up getting thrown out and redone completely just
>>> > because of stagmentation and rebase difficulty.
>>> >
>>> > WRT to the documentation debt, I think it's important to remind
>>> > everyone
>>> > that that is intentional!  I've looked at adding JS docs a couple times
>>> > now,
>>> > but when I brought it up we've decided as a group that it was lower
>>> > priority
>>> > because we did not want to commit JavaScript APIs that we know will
>>> > change.
>>> >
>>> > I think when we figure out how the front-end packaging and component
>>> > refactor will work, we definitely want to commit to **something**.
>>> >
>>> > On Mon, Jun 29, 2015 at 7:04 AM, Sylvain Corlay
>>> > <sylvain.corlay at gmail.com>
>>> > wrote:
>>> >>
>>> >> I wanted to +1 the proposal to start creating branches for new
>>> >> versions
>>> >> when a feature freeze occurs. Independently of the discussion on
>>> >> phosphor, I
>>> >> completely agree with Min on the diagnosis that there is not enough
>>> >> available parallel work.
>>> >>
>>> >> Regarding phosphor and the work on refactoring the front-end, thanks
>>> >> for
>>> >> creating the centralized phosphor notebook repository in the
>>> >> organization. I
>>> >> did some experiments lately with the widgets and did not know where
>>> >> this
>>> >> could fall, or how to share it without requiring it to install
>>> >> phosphor etc.
>>> >> Coordination is also important for new developments, even when they
>>> >> have not
>>> >> yet achieved the stability of the main components of the project.
>>> >>
>>> >> Best,
>>> >>
>>> >> Sylvain
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Jun 29, 2015 at 9:25 AM, Jason Grout <jason at jasongrout.org>
>>> >> wrote:
>>> >>>
>>> >>> On 6/26/15 19:45, Fernando Perez wrote:
>>> >>>
>>> >>> While I hear very much the spirit of what you are saying, and I
>>> >>> certainly think that we can't lose sight that the *only* thing that
>>> >>> ultimately matters is whether we serve our users well or not, there's
>>> >>> a
>>> >>> big piece that is already burning under us that probably can't wait.
>>> >>> In
>>> >>> fact, at the last dev meeting, Jason already posted his new draft
>>> >>> code
>>> >>> in this direction:
>>> >>>
>>> >>> https://github.com/jasongrout/phosphor-notebook
>>> >>>
>>> >>>
>>> >>> I just wanted to mention that I support what Fernando, Brian, and
>>> >>> Chris
>>> >>> have said about moving forward with refactoring the notebook.  We're
>>> >>> making
>>> >>> good progress, even while still ramping up.  For example, Steven
>>> >>> Silvester
>>> >>> has put a lot of work recently in porting over the kernel javascript
>>> >>> to
>>> >>> Typescript and phosphor (along with dependencies):
>>> >>>
>>> >>> https://github.com/jasongrout/phosphor-notebook/pull/2
>>> >>>
>>> >>> I just put in an in-progress pull request for documenting the API for
>>> >>> kernels, kernelspecs, and sessions (which I realized when looking at
>>> >>> the
>>> >>> kernel javascript file was woefully undocumented/incorrectly
>>> >>> documented):
>>> >>> https://github.com/jupyter/notebook/pull/173.  This shows our
>>> >>> refactoring
>>> >>> work is also having an immediate direct impact on the current
>>> >>> notebook as
>>> >>> well.
>>> >>>
>>> >>> In another message on this thread, Min suggested having a 5.x branch
>>> >>> for
>>> >>> further development, like the phosphor notebook.  For now, I think
>>> >>> the
>>> >>> phosphor notebook can proceed as a separate project - it's totally a
>>> >>> front-end thing at this point, and we're doing enough code clean-up
>>> >>> and
>>> >>> rewriting from js to typescript that I think it's all right to start
>>> >>> in a
>>> >>> fresh repo.  Which brings up another point:  can we make an official
>>> >>> Jupyter
>>> >>> repo for the phosphor notebook work, rather than using my personal
>>> >>> repo?
>>> >>> I'm happy to continue hosting
>>> >>> https://github.com/jasongrout/phosphor-notebook/ in my personal
>>> >>> github
>>> >>> account for the time being, or set up a temporary organization so we
>>> >>> can
>>> >>> collaborate more effectively, but I think it would make more sense to
>>> >>> bump
>>> >>> it up to an experimental repo in the jupyter github organization,
>>> >>> developed
>>> >>> in parallel with the current notebook.
>>> >>>
>>> >>> Thomas, one thing to consider is that us working on a phosphor
>>> >>> notebook
>>> >>> doesn't preclude interested people from enhancing the existing
>>> >>> notebook in
>>> >>> the short term.  We'd like the phosphor notebook to get to a
>>> >>> comparable
>>> >>> state with the current notebook as quickly as possible, but it will
>>> >>> still
>>> >>> take some time.
>>> >>>
>>> >>> Also, I totally agree with Thomas that dogfooding the notebook (and
>>> >>> watching/helping others actually use it to get work done) is
>>> >>> *extremely*
>>> >>> important to understanding what we want here.  And I also agree with
>>> >>> others
>>> >>> on this thread that documentation is sorely lacking.  We'll be
>>> >>> working on
>>> >>> that in the phosphor notebook as we go along too.
>>> >>>
>>> >>> Thanks,
>>> >>>
>>> >>> Jason
>>> >>>
>>> >>> _______________________________________________
>>> >>> IPython-dev mailing list
>>> >>> IPython-dev at scipy.org
>>> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> >>>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> IPython-dev mailing list
>>> >> IPython-dev at scipy.org
>>> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > IPython-dev mailing list
>>> > IPython-dev at scipy.org
>>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> >
>>>
>>>
>>>
>>> --
>>> Brian E. Granger
>>> Cal Poly State University, San Luis Obispo
>>> @ellisonbg on Twitter and GitHub
>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger at calpoly.edu and ellisonbg at gmail.com



More information about the IPython-dev mailing list