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

Wes Turner wes.turner at gmail.com
Mon Jun 29 14:28:01 EDT 2015 

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

More information about the IPython-dev mailing list