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