[IPython-dev] Proposal: soft moratorium on re-architecting for 5.0
MinRK
benjaminrk at gmail.com
Mon Jun 29 14:57:47 EDT 2015
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150629/92ace221/attachment.html>
More information about the IPython-dev
mailing list