[IPython-dev] Proposal: soft moratorium on re-architecting for 5.0
Wes Turner
wes.turner at gmail.com
Mon Jun 29 15:01:52 EDT 2015
Got it. Thanks again!
To clarify,
Use Case: build latest stable release everything from source (e.g. a
production stack)
Here's theses:
https://github.com/ipython/ipython/wiki/Dev:-Index
https://github.com/ipython/ipython/wiki/Dev:-GitHub-workflow
https://github.com/ipython/ipython/wiki/Dev:-Coding-style
On Mon, Jun 29, 2015 at 1:57 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Mon, Jun 29, 2015 at 11:56 AM, Wes Turner <wes.turner at gmail.com> wrote:
>
>> And one last thing,
>>
>> So, without a "stable" branch (e.g. "master ="),
>> all of the CI build scripts
>> are pinned to each of the separate repositories?
>>
>> Use Case: build latest everything from source.
>>
>
> Latest everything = master
>
>
>>
>>
>> On Mon, Jun 29, 2015 at 1:45 PM, Wes Turner <wes.turner at gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Jun 29, 2015 at 1:36 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>
>>>> Thanks, we are familiar with GitFlow, and have decided against using
>>>> it. We find it doesn't reflect our relationship to branches and feature
>>>> work. Working with PRs directly against master is ~always what we want, and
>>>> it is only for unusually long-running changes that we have a need for a
>>>> feature branch, and there is no distinction between develop and master.
>>>>
>>>
>>>
>>> Thanks for the feedback.
>>>
>>> * [ ] Which development branch should I fork and PR from? (master)
>>>
>>> So, each feature/ and hotfix/ branch is a PR against "develop =" (or,
>>> master).
>>>
>>> * [ ] Something like this probably works:
>>>
>>> [hubflow "branch"]
>>> master = stable
>>> develop = master
>>>
>>> [hubflow "prefix"]
>>> feature = feature/
>>> release = release/
>>> hotfix = hotfix/
>>> support = support/
>>> versiontag = v
>>>
>>> That is all.
>>>
>>>
>>>
>>>
>>>
>>>> -MinRK
>>>>
>>>> On Mon, Jun 29, 2015 at 11:28 AM, Wes Turner <wes.turner at gmail.com>
>>>> wrote:
>>>>
>>>>> 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/
>>>>>
>>>>>
>>>>> cc'ing from http://westurner.org/tools/#hubflow
>>>>>
>>>>> .. 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@github.com/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@github.com/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 <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.
>>>>>>
>>>>>> 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
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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/9e323e1f/attachment.html>
More information about the IPython-dev
mailing list