[python-committers] REMINDER: GitHub migration is scheduled for today

2017-02-10 Thread Brett Cannon 
Assuming you can't commit to Mercurial anymore and the next email from me
will either be an introduction email to our new workflow or me apologizing
for something going horribly wrong. Either way I'm hoping you will hear
from me later today. :)
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] REMINDER: GitHub migration is scheduled for today

2017-02-10 Thread Tim Golden 

On 10/02/2017 15:55, Brett Cannon wrote:

Assuming you can't commit to Mercurial anymore and the next email from
me will either be an introduction email to our new workflow or me
apologizing for something going horribly wrong. Either way I'm hoping
you will hear from me later today. :)


Good luck, and thanks to you and the team for all the hard work

TJG

___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] REMINDER: GitHub migration is scheduled for today

2017-02-10 Thread Eric Snow 
On Fri, Feb 10, 2017 at 9:00 AM, Tim Golden  wrote:
> Good luck, and thanks to you and the team for all the hard work

A big +1!

-eric
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] REMINDER: GitHub migration is scheduled for today

2017-02-10 Thread Mariatta Wijaya 
So exciting!
Good luck and thanks for all the hard work!


On Feb 10, 2017 7:56 AM, "Brett Cannon"  wrote:

> Assuming you can't commit to Mercurial anymore and the next email from me
> will either be an introduction email to our new workflow or me apologizing
> for something going horribly wrong. Either way I'm hoping you will hear
> from me later today. :)
>
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] REMINDER: GitHub migration is scheduled for today

2017-02-10 Thread Ethan Furman 

On 02/10/2017 07:55 AM, Brett Cannon wrote:


Assume you can't commit to Mercurial anymore and the next email from me
 will either be an introduction email to our new workflow or me apologizing
 for something going horribly wrong. Either way I'm hoping you will hear
 from me later today. :)


Either way you're our hero!  Thank you, thank you!

--
~Ethan~
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] REMINDER: GitHub migration is scheduled for today

2017-02-10 Thread Brett Cannon 
On Fri, 10 Feb 2017 at 08:58 Mariatta Wijaya 
wrote:

> So exciting!
> Good luck and thanks for all the hard work!
>

You're welcome, but please save the "thank you"s until after the migration
is successful. :)

-Brett


>
>
> On Feb 10, 2017 7:56 AM, "Brett Cannon"  wrote:
>
> Assuming you can't commit to Mercurial anymore and the next email from me
> will either be an introduction email to our new workflow or me apologizing
> for something going horribly wrong. Either way I'm hoping you will hear
> from me later today. :)
>
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] We are now live on GitHub!

2017-02-10 Thread Brett Cannon 
[rendered version:
https://paper.dropbox.com/doc/CPython-workflow-changes-mx1k8G6M0rg5JLy80F1r6
]

# CPython workflow changes
After more than two years, our new GitHub workflow is ready to accept
changes (you can look back to my first “[vision statement](
https://mail.python.org/pipermail/python-dev/2014-December/137472.html)” on
changing our workflow to see how things have changed since I started
working on this)! I hope you are all excited to see this finished; I know
my wife is very excited as she’s tired of listening to me talk about it for
a third of our marriage. ;)

# Thanks

First and foremost, I want to thank everyone who helped with this. Thanks
to Donald and Barry for writing the initial PEPs proposing [GitHub](
https://www.python.org/dev/peps/pep-0481/) and [GitLab](
https://www.python.org/dev/peps/pep-0507/) and Nick [pre-proposing
RhodeCode](https://www.python.org/dev/peps/pep-0474/). Thanks to everyone
on [core-workflow](https://mail.python.org/mailman/listinfo/core-workflow)
for helping out with various discussion (and which will continue to host
discussions on future improvements on our workflow). Thanks to Ezio,
Maciej, and Anish Shah for helping with the changes required to
bugs.python.org in order to keep the issue tracker around. Thanks to the
infrastructure team for helping deal with the migration of the [peps](
https://github.com/python/peps) and [devguide](
https://github.com/python/devguide) repos (especially Donald and Ernest).
Thanks to Senthil for doing the conversion of the repo itself. Thanks to
Benjamin for helping with hg.python.org stuff. Thanks to Zach for helping
with the buildbots (and the devguide). Thanks to Mariatta, Carol Willing,
Berker, Oleg, and Stéphane Wirtel for helping with the devguide. There are
also plenty of other people who have provided feedback over the past 2
years on mailing lists and in-person.

# What has changed

The documentation in the [devguide](https://cpython-devguide.readthedocs.io)
should be up-to-date, so don’t worry about keeping this around as a
reference. Consider this more of an announcement letter to get people
quickly up-to-speed and excited about the new workflow.

## The location of the code repository

CPython’s code now lives at https://github.com/python/cpython .
hg.python.org/cpython is and will stay read-only (no determination has been
made as to how long the Mercurial repository will be kept running). It
should also be mentioned that we are doing squash commits and not rebased
commits or merge commits as some projects on GitHub do. This basically
means we will continue to have a single contribution lead to a single
commit, keeping our history linear and compact.

To up the bus factor on the new repository, I have set up a team for
[Python release managers](
https://github.com/orgs/python/teams/python-release-managers) and made them
administrators on the repository. I don’t necessarily expect RMs to use
this power, but it’s there in case any of them need to change a setting in
order to get a release out (to be upfront about it, I’m also in the team as
its creator, but I have administrative privileges for the [Python team](
https://github.com/python) on GitHub so it doesn’t change what I’m able to
do).

## Specifying issue numbers

Traditionally we have specified issues as “Issue #”. The problem with
this format is that [GitHub automatically links](
https://help.github.com/articles/autolinked-references-and-urls/#issues-and-pull-requests)
text in this format to GitHub issues and pull requests. While our
repository will initially have no issues or PRs to automatically link to,
this might not be true long-term (GitHub does the automatic linking eagerly
at push time, so there’s no worry for older commit messages; we actually
almost mutated the history to match the new format but in the end I made
the decision not to as I didn’t consult with python-committers prior to the
migration to make sure such a change was acceptable to everyone).

To avoid this issue we are going to start specifying issues as “bpo-”.
This clearly delineates that issue numbers directly relate to
bugs.python.org since “[namespaces are one honking great idea](
https://www.python.org/dev/peps/pep-0020/)”. This is also a format that
GitHub supports — “GH-” — as well as JIRA who [lets you specify the
prefix](
https://confluence.atlassian.com/adminjiraserver072/changing-the-project-key-format-828787722.html),
so there’s precedent for choosing it. This change applies both to
`[Misc/NEWS](
https://cpython-devguide.readthedocs.io/committing.html#what-s-new-and-news-entries)`
and in [commit messages](
https://cpython-devguide.readthedocs.io/committing.html#commit-messages).
Mentioning an issue this way in a pull request title or comment will
connect the PR to the corresponding issue on bugs.python.org. Mentioning an
issue this way in a commit message will cause a comment to show up in the
issue relating to the commit.

## Cherry-picking instead of merging

W

Re: [python-committers] We are now live on GitHub!

2017-02-10 Thread Antoine Pitrou 

Le 11/02/2017 à 00:19, Brett Cannon a écrit :
> 
> # What has improved
> ## Accepting PRs through GitHub’s web UI
> 
> While using hg.python.org , all commits had to be
> done through Mercurial’s CLI. With the move to GitHub we gain the
> ability to accept pull requests through a web UI. While this will only
> accept the change into the branch it was submitted against (which can be
> changed in the web UI), for situations where a change does not need to
> be backported it will allow for easier acceptance of a change. (When a
> change does need to be backported this is when you need to cherry-pick
> and that requires using the git CLI). If a change does need to be
> cherry-picked into an older branch you can either wait to accept the PR
> when you have a clone to work with or accept the change into master now
> and then cherry-pick later when you have a clone available.

To make sure I'm understanding this, this means any cherry-pick goes
through its own PR, right?  i.e. if a change has to go into master, 3.6
and 2.7, three PRs have to be opened?

(and what do you mean with "when you have a clone available"?)

> While this doesn’t solve all testing scenarios (e.g. this doesn’t test a
> macOS or Windows-related change due to the added hours it take for a PR
> to be “green” when run on Travis for macOS or AppVeyor for Windows),

In my experience, build times on AppVeyor have recently become more
competitive with Travis-CI (though mostly because Travis-CI seems to
have become slower).  However, AppVeyor doesn't seem to schedule several
build configurations in parallel, so this is best used as a smoke test
with a single build configuration (also, the test suite could be run in
a less thorough mode).


Thanks for all the work!

Regards

Antoine.
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] We are now live on GitHub!

2017-02-10 Thread Donald Stufft 

> On Feb 10, 2017, at 6:19 PM, Brett Cannon  wrote:
> 
> While this doesn’t solve all testing scenarios (e.g. this doesn’t test a 
> macOS or Windows-related change due to the added hours it take for a PR to be 
> “green” when run on Travis for macOS or AppVeyor for Windows)


Just an FYI, I was talking to a friend in Travis and he suggests in the next 
few weeks they’re going to get a lot more macOS capacity. We might want to try 
this again in a few weeks and see if their new capacity is enough that the lead 
time is good enough.

—
Donald Stufft



___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] We are now live on GitHub!

2017-02-10 Thread Brett Cannon 
On Fri, 10 Feb 2017 at 15:50 Antoine Pitrou  wrote:

>
> Le 11/02/2017 à 00:19, Brett Cannon a écrit :
> >
> > # What has improved
> > ## Accepting PRs through GitHub’s web UI
> >
> > While using hg.python.org , all commits had to be
> > done through Mercurial’s CLI. With the move to GitHub we gain the
> > ability to accept pull requests through a web UI. While this will only
> > accept the change into the branch it was submitted against (which can be
> > changed in the web UI), for situations where a change does not need to
> > be backported it will allow for easier acceptance of a change. (When a
> > change does need to be backported this is when you need to cherry-pick
> > and that requires using the git CLI). If a change does need to be
> > cherry-picked into an older branch you can either wait to accept the PR
> > when you have a clone to work with or accept the change into master now
> > and then cherry-pick later when you have a clone available.
>
> To make sure I'm understanding this, this means any cherry-pick goes
> through its own PR, right?  i.e. if a change has to go into master, 3.6
> and 2.7, three PRs have to be opened?
>

Yes.


>
> (and what do you mean with "when you have a clone available"?)
>

Have a git checkout locally.


>
> > While this doesn’t solve all testing scenarios (e.g. this doesn’t test a
> > macOS or Windows-related change due to the added hours it take for a PR
> > to be “green” when run on Travis for macOS or AppVeyor for Windows),
>
> In my experience, build times on AppVeyor have recently become more
> competitive with Travis-CI (though mostly because Travis-CI seems to
> have become slower).  However, AppVeyor doesn't seem to schedule several
> build configurations in parallel, so this is best used as a smoke test
> with a single build configuration (also, the test suite could be run in
> a less thorough mode).
>

If someone wants to submit a PR to add a config and see how long it takes
we can always experiment.


>
>
> Thanks for all the work!
>

Welcome!

-Brett


>
> Regards
>
> Antoine.
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/