[Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Wes Turner]

On Sun, Nov 23, 2014 at 2:38 PM, Donald Stufft <donald at stufft.io> wrote:

>
> > On Nov 23, 2014, at 3:03 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> >
> > The next point is that there is no easy way to change the target branch
> of
> > a pull request (on github or bitbucket).  People will usually make
> patches
> > against the master branch unless told differently explicitly, which means
> > that the pull request will also be against the master branch.  Which
> means,
> > close the PR, ask submitter to resubmit against 3.x branch, or do it
> > yourself.
>
> This in particular is not really true on Github at least. By default PRs
> are
> made against whichever branch you have configured as the default branch in
> the Github UI. This does default to master but it doesn’t have to be, for
> instance pip has this configured for the develop branch. Although I think
> this specific point is moot because if things were on Git it’d probably
> make
> the most sense to have the default integration branch be ``master`` just
> like
> for the Hg repos they use default.
>

I'm liking the hubflow/gitflow git workflow extensions, where "trunk" is
also develop.
There are feature branches, hotfix branches, release branches, etc.

  # .git/config : "prefix": "v"
  git hf release start 0.1.0
  echo "0.1.0" >> VERSION.txt
  git hf release finish 0.1.0  # (merges, release commit message, return to
develop)

These are some of the most helpful (git) branching diagrams I've ever seen:

* https://datasift.github.io/gitflow/IntroducingGitFlow.html
* http://www.infoq.com/articles/agile-version-control

The support for tagging releases is helpful. (It's possible to host package
releases for various platforms as GitHub releases).


>
> Even if someone makes a PR against the wrong branch, it “degrades” into
> essentially the same UX as you have now, you can turn a PR into a patch by
> adding a .patch or .diff to the end of the PR URL and then you have a patch
> file. In additional github makes it easy to check out PRs directly with
> only a
> minor bit of one time configuration in your local clone. I can checkout
> any PR
> by doing ``git checkout pr/1`` (replacing 1 with whatever the number is).
>
> Honestly the worst part about someone sending a PR to the wrong branch is
> it
> degrades into the same terrible UX that *every* patch has to go through on
> a hg.python.org repository right now.
>


In this respect, hg mq is tightly integrated, and written in Python. Patch
Queue / build system of VCS integration could be helpful.

* http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html
* http://hgbook.red-bean.com/read/advanced-uses-of-mercurial-queues.html

I agree that

- [ ] Build status displayed on the PR [is an extremely useful feature for
a code forge to offer]
- [ ] Markdown/ReStructuredText Checkboxes are helpful

  * GitHub: Issues
  * BitBucket: PR Task Lists integrated with review.

My mouse cursor tends to be near the scroll bar alot, as well.


--

https://en.wikipedia.org/wiki/Forge_(software)#Technology

https://en.wikipedia.org/wiki/Comparison_of_open-source_software_hosting_facilities


> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
>



-- 
Wes Turner
https://westurner.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141123/b57a7b4e/attachment.html>