[IPython-dev] Proposal: soft moratorium on re-architecting for 5.0
Wes Turner
wes.turner at gmail.com
Mon Jun 29 14:45:12 EDT 2015
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150629/1efc6570/attachment.html>
More information about the IPython-dev
mailing list