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