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

Wes Turner wes.turner at gmail.com
Mon Jun 29 14:33:56 EDT 2015


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


More information about the IPython-dev mailing list