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
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
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
>
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.
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
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
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
> 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
>
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