Re: [python-committers] Travis CI: macOS is now blocking -- remove macOS from Travis CI?

2017-09-20 Thread Nick Coghlan
On 20 September 2017 at 12:04, Victor Stinner wrote: > Python tests are very stable on macOS (on buildbots). So yes, it's an issue > specific to Travis. Although as Alex explains, that isn't really Travis CI's *fault* - it's an artifact of the licensing design for macOS

[python-committers] Should I merge a PR that I approved if it was written by a different core developer?

2017-09-20 Thread Victor Stinner
Hi, Before the GitHub era, in the old "Mercurial era", the unwritten rule was to not merge a patch written by a developer who has the commit bit, to not "steal" his/her work. The old workflow (patches attached to the bug tracker) didn't allow to easily keep the author. You had to find the author

Re: [python-committers] Should I merge a PR that I approved if it was written by a different core developer?

2017-09-20 Thread Guido van Rossum
On Wed, Sep 20, 2017 at 2:27 PM, Victor Stinner wrote: > Before the GitHub era, in the old "Mercurial era", the unwritten rule > was to not merge a patch written by a developer who has the commit > bit, to not "steal" his/her work. The old workflow (patches attached >

Re: [python-committers] Should I merge a PR that I approved if it was written by a different core developer?

2017-09-20 Thread Guido van Rossum
On Wed, Sep 20, 2017 at 2:49 PM, Victor Stinner wrote: > > I think it's a good idea in many cases, but not required. > > I'm not sure that I understood correctly, what is a good idea? To > merge the PR if I consider that it's now good enough to be merged? > Sorry, yes.

Re: [python-committers] Should I merge a PR that I approved if it was written by a different core developer?

2017-09-20 Thread Berker Peksağ
On Thu, Sep 21, 2017 at 12:27 AM, Victor Stinner wrote: > Hi, > > Before the GitHub era, in the old "Mercurial era", the unwritten rule > was to not merge a patch written by a developer who has the commit > bit, to not "steal" his/her work. The old workflow (patches

Re: [python-committers] Should I merge a PR that I approved if it was written by a different core developer?

2017-09-20 Thread Ezio Melotti
On Wed, Sep 20, 2017 at 11:27 PM, Victor Stinner wrote: > Hi, > > Before the GitHub era, in the old "Mercurial era", the unwritten rule > was to not merge a patch written by a developer who has the commit > bit, to not "steal" his/her work. The old workflow (patches

Re: [python-committers] Should I merge a PR that I approved if it was written by a different core developer?

2017-09-20 Thread Nick Coghlan
On 21 September 2017 at 07:27, Victor Stinner wrote: > Hi, > > Before the GitHub era, in the old "Mercurial era", the unwritten rule > was to not merge a patch written by a developer who has the commit > bit, to not "steal" his/her work. The old workflow (patches

Re: [python-committers] Should I merge a PR that I approved if it was written by a different core developer?

2017-09-20 Thread Victor Stinner
> I think it's a good idea in many cases, but not required. I'm not sure that I understood correctly, what is a good idea? To merge the PR if I consider that it's now good enough to be merged? > E.g. you may be OK > with the diff but still ask the author to clean up some small nits, and then >

[python-committers] [RELEASE] Python 3.6.3rc1 and 3.7.0a1 are now available for testing and more

2017-09-20 Thread Ned Deily
The Python build factories have been busy the last several weeks preparing our fall lineup of releases. Today we are happy to announce three additions: 3.6.3rc1, 3.7.0a1, and 3.3.7 final, which join last weekend's 2.7.14 and last month's 3.5.4 bug-fix releases and 3.4.7 security-fix update