On Fri, 21 Apr 2017 at 15:33 Victor Stinner
wrote:
> Ah, I found a workaround: Firefox on Android has a "[x] See the computer
> version" option which allows the merge!?
>
> Victor
>
> Le 22 avr. 2017 12:29 AM, "Victor Stinner" a
> écrit :
>
>> Hi,
>>
>> I tried to merge a pull request on my phon
On Tue, 25 Apr 2017 at 17:00 Terry Reedy wrote:
> On 4/25/2017 11:00 AM, Barry Warsaw wrote:
> > On Apr 24, 2017, at 09:32 PM, Ethan Furman wrote:
> >>On 04/21/2017 03:29 PM, Victor Stinner wrote:
>
> (In the context of having a patch blocked by the blind Codecov robot ...)
>
> >>> I dislike code
On Wed, 26 Apr 2017 at 22:36 Terry Reedy wrote:
> On 4/26/2017 1:45 PM, Brett Cannon wrote:
> >
> > On Tue, 25 Apr 2017 at 17:00 Terry Reedy > <mailto:tjre...@udel.edu>> wrote:
>
> > While I use code coverage to improve automated unittesting, I am
>
On Fri, 28 Apr 2017 at 02:19 Michael Foord wrote:
>
>
> On 28/04/17 01:49, Terry Reedy wrote:
> > On 4/27/2017 3:44 PM, Brett Cannon wrote:
> >>
> >>
> >> On Wed, 26 Apr 2017 at 22:36 Terry Reedy >> <mailto:tjre...@udel.edu>> wrot
So Donald is right that the reason we don't have macOS builds through
Travis is due to the fact that back in February they had a horrible backlog
and added too much time to the total build.
But as Alex pointed out, Travis has subsequently increased their macOS
fleet and given the Python organizati
I just touched up
https://github.com/python/cpython/blob/master/.github/CONTRIBUTING.rst to
explicitly mention that only code review issues should be discussed on
GitHub.
On Mon, 1 May 2017 at 15:32 Christian Heimes wrote:
> Hi all,
>
> since our move to Github I noticed a major increase in inco
On Tue, 2 May 2017 at 11:29 Terry Reedy wrote:
> On 5/2/2017 10:07 AM, R. David Murray wrote:
> > On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg"
> wrote:
>
> >> IMO, it's much easier for everyone to just always point people
> >> to BPO for discussions and keep PRs reserved for code reviews.
On Wed, 3 May 2017 at 13:42 Terry Reedy wrote:
> On 5/3/2017 1:25 PM, Brett Cannon wrote:
> >
> > On Tue, 2 May 2017 at 11:29 Terry Reedy > <mailto:tjre...@udel.edu>> wrote:
>
> > It would easier to move discussion to bpo if there were a clickable
&g
I newer didn't have that issue (it failed for testing reasons):
https://travis-ci.org/python/cpython/jobs/228820650.
I tried to re-run the build step to see if I could reproduce but the PR is
already merged so I can't check. But I'm a little surprised it tried to
build the sdist since coverage.py
regen-all change
https://github.com/python/cpython/commit/a5c62a8e9f0de6c4133825a5710984a3cd5e102b
.
I'm not quite sure how the build changes broke distutils, though.
On Thu, 4 May 2017 at 10:54 Brett Cannon wrote:
> I newer didn't have that issue (it failed for testing reasons):
>
Thanks, Victor!
On Thu, 4 May 2017 at 14:32 Victor Stinner wrote:
> 2017-05-04 22:51 GMT+02:00 Victor Stinner :
> > It seems like a real bug and a regression, I opened an issue to track it:
> > http://bugs.python.org/issue30273
>
> Ok, it should be fixed by my commit:
>
> https://github.com/pyth
Just so no one thinks anything fishy is going on, I wanted to let the team
know that I created https://github.com/bedevere-bot and now have Bedevere
using this account instead of piggybacking off of
https://github.com/the-knights-who-say-ni. I figured they should be
separate for security reasons as
People didn't always remember to add the labels and they were redundant
with people specifying the branch in the title along with the PR that the
cherry-pick originated from (e.g. "[3.6] Something changed (GH-12345)").
___
python-committers mailing list
p
On Sat, 13 May 2017 at 12:59 Brett Cannon wrote:
> People didn't always remember to add the labels and they were redundant
> with people specifying the branch in the title along with the PR that the
> cherry-pick originated from (e.g. "[3.6] Something changed (GH-12345)&quo
Looks like they added some new warnings that are causing the docs build to
fail (e.g. https://travis-ci.org/python/cpython/jobs/232903226 and
https://travis-ci.org/python/cpython/jobs/232897796).
I will see if I have time to fix this before I leave for PyCon US today,
but there's no guarantee. If
I replied on the PR.
On Tue, 16 May 2017 at 11:09 Mariatta Wijaya
wrote:
> It passes now : https://github.com/python/cpython/pull/1612
>
> Ok to merge?
>
> Mariatta Wijaya
>
> On Tue, May 16, 2017 at 10:31 AM, Brett Cannon wrote:
>
>> Looks like they added some
to update his PR to fix it.)
Thanks to Mariatta, Kushal, Zachary, Senthil, and Serhiy for all chipping
in to help fix this in a timely manner and contain the number of broken PRs
because of it.
On Tue, 16 May 2017 at 10:31 Brett Cannon wrote:
> Looks like they added some new warnings that
On Wed, 17 May 2017 at 11:27 Victor Stinner
wrote:
> Hi,
>
> I wanted to wait a little bit before giving back my feedback on the
> new workflow. I just attend Brett Canon's talk at the Language Summit.
> So here are my misc notes on the new workflow.
>
> * Is there anyone already working on the w
While at the PyCon US sprints the idea came up of offering Carol Willing
developer privileges. Everyone at the table -- about 6 of us -- liked the
idea and Carol also said she would happy to become a core dev, so I'm
officially putting her forward for consideration.
For those of you who don't know
2017 at 08:16 Guido van Rossum wrote:
> OK, I think we have enough +1 votes... Brett, will you make it happen?
>
> On Wed, May 24, 2017 at 12:25 AM, Nick Coghlan wrote:
>
>> On 24 May 2017 at 04:15, Brett Cannon wrote:
>> > While at the PyCon US sprints the idea c
https://github.com/python/cpython/labels now have prefixes for all labels
to make it easier to find the relevant labels for some kind of
classification. For instance, all the labels for the type of PR -- e.g.
bugfix, enhancement, etc. -- now all have a "type-" prefix so you know what
your options a
After reading a tweet from Nick (
https://twitter.com/ncoghlan_dev/status/868343982698266624) I realized it
probably would have been good to label PRs from sprinters at PyCon US so
they could get priority while the contributor was in the room or at least
try to address them quickly after the sprint
At the moment Travis is not running the test build (it's actually not even
listing it as a build). You can look at master, 3.6, or 3.5 to see that
only the docs and coverage builds are being run:
https://travis-ci.org/python/cpython/branches . I don't know why this is as
it was fine yesterday and t
n/pull/1879
>
>
>
> On May 30, 2017 4:08 PM, "Brett Cannon" wrote:
>
>> At the moment Travis is not running the test build (it's actually not
>> even listing it as a build). You can look at master, 3.6, or 3.5 to see
>> that only the docs and coverage
I just wanted to quickly let people know I lifted Wes' two-month ban and
emailed him to notify him of the lifting.
On Fri, 31 Mar 2017 at 14:40 Brett Cannon wrote:
> In the (long) discussion of
> https://github.com/python/core-workflow/issues/6, Wes Turner began to do
> his us
; Le 02/06/2017 à 18:47, Brett Cannon a écrit :
> > I just wanted to quickly let people know I lifted Wes' two-month ban and
> > emailed him to notify him of the lifting.
> >
> > On Fri, 31 Mar 2017 at 14:40 Brett Cannon > <mailto:br...@python.org>> wrote:
&g
I have turned on macOS builds on Travis for all active branches, but for
now the builds are allowed to fail. The latter detail is so that we can be
sure that the tests are stable on Travis before blocking on it as well as
see if the added build time is acceptable for blocking a PR on. If the
tests
On Tue, 13 Jun 2017 at 00:17 Victor Stinner
wrote:
> Hi,
>
> Would it be possible to give the commit bit to Julien Palards on the
> following project (only on this project)?
>
> https://github.com/python/docsbuild-scripts/pulls
>
> His GitHub account is "JulienPalard":
>
> https://github.com/
On Tue, 13 Jun 2017 at 15:37 Victor Stinner
wrote:
> Le 14 juin 2017 00:29, "Brett Cannon" a écrit :
>
> It is, but the infrastructure team owns that repo, not Python core.
>
> -Brett
>
>
> Oh, I didn't know. Is it possible to see who owns a GitHub Python
On Wed, 14 Jun 2017 at 07:46 Victor Stinner
wrote:
> Hi,
>
> The CPython workflow was enhanced to get pre-commit CI checks. That's
> a huge win, thank you for that... But, sometimes, a change can still
> break many buildbots, bugs which weren't catched by pre-commit checks
> (Travis CI/Linux and
On Thu, 15 Jun 2017 at 06:39 Victor Stinner
wrote:
> 2017-06-15 5:31 GMT+02:00 Nick Coghlan :
> > I'm not necessarily opposed to such a policy change, but if folks
> > really want guaranteed green post-merge buildbots for all platforms
> > (rather than just guaranteed green for Linux & Windows, s
I've made Python core able to read the buildmaster-config repo.
On Wed, 14 Jun 2017 at 13:53 Victor Stinner
wrote:
> 2017-06-14 22:40 GMT+02:00 Brett Cannon :
> >> Oh, I didn't know. Is it possible to see who owns a GitHub Python
> project
> >> at https://gith
On Fri, 16 Jun 2017 at 03:40 Victor Stinner
wrote:
> 2017-06-16 10:37 GMT+02:00 Nick Coghlan :
> > Hopefully reversions will continue to be rare (since relatively few
> > changes are likely to be as platform dependent as PEP 538, and
> > Windows/*nix differences are already covered in pre-merge C
When you create a backport PR, if the title is formatted as, e.g. "[3.6]
stuff that changed (GH-1234)", then Bedevere will remove the "needs
backport to 3.6" label on the GH-1234 PR and leave a comment linking to the
backport PR that triggered the label removal.
On Fri, 16 Jun 2017 at 13:24 Ethan Furman wrote:
> On 06/16/2017 09:48 AM, Brett Cannon wrote:
>
> > Maybe we should amend PEP 11 to say that whomever volunteers to maintain
> a platform
> > must make sure that platform's buildbot is not red for longer than a
> mo
On Tue, 20 Jun 2017 at 08:37 Victor Stinner
wrote:
> 2017-06-20 16:56 GMT+02:00 Mariatta Wijaya :
> > I think it's because there was no 'needs backport to 3.4' label from PR
> > 1849, so it doesn't make the comment about 3.4 backport PR.
>
> Oh, I see. These labels don't exist :-) Maybe we should
On Thu, 22 Jun 2017 at 02:32 Larry Hastings wrote:
>
>
> On 06/22/2017 01:04 AM, Victor Stinner wrote:
>
> About the cipher list in ssl, the change itself is simple but it's to
> blacklist DES and 3DES since it has been proved that these ciphers are
> really too weak nowadays:
>
> http://python-s
I hope the bot works as expected! I worked hard to make it appropriately
paranoid to make Van and other lawyers happy! ;)
On Wed, 21 Jun 2017 at 11:03 Victor Stinner
wrote:
> Hi,
>
> Fun fact: I cherry-picked a change from libexpat into Modules/expat
> (VS2008 fix for stdint.h), and I kept the a
If people would like to see the bpo link be automatically appended to the
original PR message, feel free to help with
https://github.com/python/bedevere/issues/3 :)
On Wed, 21 Jun 2017 at 13:38 Mariatta Wijaya
wrote:
> PR 2304 is merged. "View Details" still exists (scroll all the way down).
>
>
On Fri, 23 Jun 2017 at 09:28 R. David Murray wrote:
> On Wed, 21 Jun 2017 13:37:22 -0700, Mariatta Wijaya <
> mariatta.wij...@gmail.com> wrote:
> > PR 2304 is merged. "View Details" still exists (scroll all the way down).
> >
> > When the PR is not yet merged (e.g.
> > https://github.com/python/c
On Sat, 24 Jun 2017 at 09:22 Antoine Pitrou wrote:
>
> Le 24/06/2017 à 18:05, Terry Reedy a écrit :
> >
> > I use the same
> > email for both github and bpo. I can't see if your github email is the
> > same as your primary bpo email and I don't know if that makes any
> > difference.
>
> I added
On Sat, 24 Jun 2017 at 09:46 Larry Hastings wrote:
> On 06/24/2017 09:40 AM, Terry Reedy wrote:
>
> On 6/23/2017 11:24 PM, Larry Hastings wrote:
>
> > You can install blurb from pip:
> >
> > % pip3.6 install blurb
>
> This does not seem to work right. On Windows:
>
> C:\Users\Terry>py -3 -m
I just pushed blurb 1.0.0.post1 which re-packages everything using flit so
there's a blurb.py and an entry point for the `blurb` command. That should
meet everyone's needs for launching the tool.
On Sat, 24 Jun 2017 at 09:54 Brett Cannon wrote:
> On Sat, 24 Jun 2017 at 09:46 L
I just pushed a change to master, 3.6, and 3.5 where
Tools/scripts/patchcheck.py now has a --travis option which will run the
whitespace fixers from `make patchcheck` but trigger a Travis build failure
if any changes were necessary. This only runs on Linux so it is a PR
blocker, but also so it isn'
On Sun, Jun 25, 2017, 07:00 R. David Murray, wrote:
> On Sat, 24 Jun 2017 00:33:13 -0000, Brett Cannon wrote:
> > On Fri, 23 Jun 2017 at 09:28 R. David Murray
> wrote:
> >
> > > On Wed, 21 Jun 2017 13:37:22 -0700, Mariatta Wijaya <
> > > mariatta.wij.
On Mon, 26 Jun 2017 at 09:22 Victor Stinner
wrote:
> 2017-06-26 17:25 GMT+02:00 Antoine Pitrou :
> > Given that it doesn't hurt to keep it, I would rather keep it. It
> > allows to quickly test for OS X-specific issues.
>
> According to my bad experience of today, it took longer than 1h30 to
> g
On Mon, 10 Jul 2017 at 07:57 Berker Peksağ wrote:
> On Mon, Jul 10, 2017 at 4:14 PM, Serhiy Storchaka
> wrote:
> > When a PR is consistent on several commits, the final commit message
> > composed by GitHub contains messages of all these commits: "fix typo",
> > "address yyy comments", "revert z
In preparation of fully moving over to blurb and per-file news entries (I
don't have an ETA from Larry on when he plans to do explode Misc/NEWS into
individual files), the "trivial" label has been replaced with a "skip
issue" label to signal that the issue number check should be skipped. The
plan i
On Sun, Jul 16, 2017, 07:10 Victor Stinner,
wrote:
> 2017-07-14 20:33 GMT+02:00 Brett Cannon :
> > In preparation of fully moving over to blurb and per-file news entries (I
> > don't have an ETA from Larry on when he plans to do explode Misc/NEWS
> into
> > ind
A quick thanks from me, Ned, for stepping forward to help 3.3 pine for the
fjords.
On Sat, Jul 15, 2017, 14:51 Ned Deily, wrote:
> Python 3.3 is fast approaching its end-of-life date, 2017-09-29. Per our
> release policy, that date is five years after the initial release of 3.3,
> 3.3.0 final o
On Sun, 16 Jul 2017 at 15:22 Victor Stinner
wrote:
> 2017-07-16 16:10 GMT+02:00 Victor Stinner :
> > What is the benefit of converting old Misc/NEWS entries?
>
> I guess that the benefit is to use a single format for all NEWS
> entries. I understand that it will ease the build of the changelog.
>
On Mon, 17 Jul 2017 at 05:52 Nick Coghlan wrote:
> On 17 July 2017 at 21:29, Antoine Pitrou wrote:
> >
> > Nevermind, it seems to have come back online.
>
> I've occasionally seen that not just with Appveyor, but also with
> other pre-merge CI systems: it seems like their event monitoring queue
I set up the account and Zach has access. If you have instructions to point
me at, Paul, I can see if I can set it up.
On Tue, 18 Jul 2017 at 09:26 Paul Moore wrote:
> You need to log on as the Appveyor account in order to manage builds.
> It's possible to link a Github team with an Appveyor adm
e issues.
>
>
> == Git branches ==
>
> Having to create a local Git branch, push it to my repository and
> create PR is more work than attaching a patch file to bugs.python.org.
> It requires to be more organized to track my "local" Git branches.
>
> I'm now
On Tue, 18 Jul 2017 at 11:08 Zachary Ware
wrote:
> On Tue, Jul 18, 2017 at 12:23 PM, Brett Cannon wrote:
> > I set up the account and Zach has access. If you have instructions to
> point
> > me at, Paul, I can see if I can set it up.
>
> Looks like https://ci.appvey
On Tue, 18 Jul 2017 at 12:54 Barry Warsaw wrote:
> On Jul 18, 2017, at 15:21, R. David Murray wrote:
> >
> > I much prefer rietveld over github reviews, but I also much prefer the
> > integration between the bug tracker and github over the minimal
> > integration we had for rietveld. Thanks to
On Tue, 18 Jul 2017 at 16:06 Terry Reedy wrote:
> On 7/18/2017 2:31 PM, Brett Cannon wrote:
>
> > Once again, glad the goals are panning out. :) Key thing has always been
> > to increase our bandwidth and part of that was always to push more on to
> > contributors
On Tue, 18 Jul 2017 at 13:33 Paul Moore wrote:
> On 18 July 2017 at 20:59, Brett Cannon wrote:
> > I went ahead and clicked buttons. :) I set Python core as users and
> release
> > managers as admins (on top of Zach and me already being admins).
>
> Cool - when I log i
On Tue, 18 Jul 2017 at 13:10 Victor Stinner
wrote:
> 2017-07-18 21:21 GMT+02:00 R. David Murray :
> > On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner <
> victor.stin...@gmail.com> wrote:
> >> I'm just not unconfortable with the fact that an approval is kept even
> >> if the PR is modified afte
Thought people might be interested in this post (specifically the email
header info) since I know some have said they have had issues in managing
email notifications:
https://github.com/blog/2399-managing-large-numbers-of-github-notifications
___
python-c
On Wed, 19 Jul 2017 at 08:18 R. David Murray wrote:
> On Tue, 18 Jul 2017 23:13:41 -0000, Brett Cannon wrote:
> > Do realize that setting is part of requiring a review for pull requests:
> >
> https://help.github.com/articles/enabling-required-reviews-for-pull-requests/
>
If you look at the exact commands it's configure, make, and then make
regen-all clinic. My guess is that last command is touching files in such a
way that the make bulidbottest is causing make to rebuild some files.
On Sun, Jul 23, 2017, 02:39 Antoine Pitrou, wrote:
>
> Hi,
>
> I've noticed that
So are you requesting we stop building on AppVeyor?
On Tue, Jul 25, 2017, 17:31 Victor Stinner,
wrote:
> Hi,
>
> It's the second time today that I get this error on a PR:
>
>"continuous-integration/appveyor/pr — AppVeyor was unable to build
> non-mergeable pull request"
>
> With such failure
On Tue, Jul 25, 2017, 19:26 Victor Stinner,
wrote:
> 2017-07-26 4:22 GMT+02:00 Brett Cannon :
> > So are you requesting we stop building on AppVeyor?
>
> No. I would like to know how to fix the AppVeyor issue :-) Is it a bug
> under our control?
>
I don't see ho
On Sat, 29 Jul 2017 at 09:05 Terry Reedy wrote:
> On 7/29/2017 4:40 AM, Paul Moore wrote:
> > On 28 July 2017 at 23:30, Mariatta Wijaya
> wrote:
> >>> 1. Section 32.2 in the Git bootcamp section - is there any reason to
> >>> use git@github URLs for the clones? I normally always use
> >>> https:
For those of you who have not noticed, mention-bot is no more. We were
using the free instance that Facebook provided, but it seems to have fallen
over and it doesn't look like it's going to get fixed soon (
https://github.com/facebook/mention-bot/issues/230).
But while mention-bot was down, GitHu
On Wed, 2 Aug 2017 at 11:20 Terry Reedy wrote:
> On 8/2/2017 10:37 AM, Nick Coghlan wrote:
> > On 2 August 2017 at 07:09, Christian Heimes
> wrote:
> >> I suggested teams to make the file a bit easier to maintain. The rule
> >> format works differently than the old mentionbot format. In the old
On Wed, 2 Aug 2017 at 16:01 Steve Dower wrote:
> Should we seed the teams from the experts list?
>
I thought about it and decided not to because (a) the experts list is keyed
on bugs.python.org account names and so I didn't want to have to look up
details, (b) this is much more automated than be
https://github.com/orgs/python/teams/import-team/members
If anyone else wants to be on the team to be notified for import-related
PRs then please just let any of us know and we can add you (I'm making
everyone who's a member of a team an admin for that team so we don't have
unnecessary bottlenecks
On Wed, 9 Aug 2017 at 01:55 Victor Stinner wrote:
> Hi,
>
> Python 3.5 entered security fix only mode. Should we now remove the
> "needs backport to 3.5" label? Other security only branches don't have
> this label neither (3.3 and 3.4).
>
Seems reasonable to me since you will need to get Larry's
No one has said anything, so I will delete the label sometime today.
On Wed, 9 Aug 2017 at 12:20 Brett Cannon wrote:
> On Wed, 9 Aug 2017 at 01:55 Victor Stinner
> wrote:
>
>> Hi,
>>
>> Python 3.5 entered security fix only mode. Should we now remove the
>> &qu
>
> On Aug 11, 2017 12:04 PM, "Brett Cannon" wrote:
>
>> No one has said anything, so I will delete the label sometime today.
>>
>> On Wed, 9 Aug 2017 at 12:20 Brett Cannon wrote:
>>
>>> On Wed, 9 Aug 2017 at 01:55 Victor Stinner
>>&
Now that all branches support blurb, I have added a status check for a news
entry. If a PR doesn't require a news entry then simply set the "skip news"
label and the status check will then pass. When there is no news entry the
Details link of the failing status check points to the appropriate part
Last year I took the month of October off from volunteering on Python to
prevent burn-out and to just take some time to reflect. It turned out to be
a great decision as I came out of the break feeling much better about
volunteering to work on Python and what I needed to do to stay grounded (it
has
FYI https://github.com/orgs/python/teams/windows-team/members . Steve is
working on a PR for automatic notification for the team at
https://github.com/python/cpython/pull/3089 .
___
python-committers mailing list
python-committers@python.org
https://mail.
On Wed, 16 Aug 2017 at 12:03 Terry Reedy wrote:
> On 8/16/2017 2:32 PM, Antoine Pitrou wrote:
>
> > One of my PR builds got an AppVeyor failure in test_asyncgen
> > and I really doubt it is due to the PR itself:
> > https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.5366#L682
>
> The fi
On Thu, 17 Aug 2017 at 15:28 Larry Hastings wrote:
>
>
> On 08/14/2017 03:22 PM, Brett Cannon wrote:
>
> The reason I'm making this announcement now is I know this coincides with
> the core sprint next month so if anyone has anything they want to ask me
> before that,
On Tue, 19 Sep 2017 at 15:04 Barry Warsaw wrote:
> On Sep 19, 2017, at 15:32, Victor Stinner
> wrote:
> >
> > The macOS job has been removed from Travis CI at the beginnig of the
> > CPython sprint two weeks ago. Since the macOS build was removed, I'm
> > less annoyed by Travis CI: it seems more
+1 for the list Victor and Antoine have here!
On Fri, 22 Sep 2017 at 09:48 Antoine Pitrou wrote:
>
> Hi Victor,
>
> Thank you, this is a useful write-up!
>
> Le 22/09/2017 à 16:26, Victor Stinner a écrit :
> >
> > I started to list "responsabilities" (is it the correct word?) of a
> > core devel
You can ask me or any release manager for access (which I just gave you :) .
On Mon, 25 Sep 2017 at 20:54 Mariatta Wijaya
wrote:
> Hi,
>
> As part of maintaining miss-islington, I think it would be great if I
> could see the GitHub webhook events for the CPython repo, just to make it
> easier fo
I noticed today that out of about 19 pages of issues, only the first 5 have
"awaiting" labels. Would people object if I back-filled those open issues
lacking an "awaiting" label? For those that have a "changes requested"
review a comment that said roughly "we noticed there's a review asking for
cha
pdated the patch, please re-review", rather than magic
> inside baseball language?
>
> Alex
>
> On Fri, Oct 6, 2017 at 5:29 PM, Brett Cannon wrote:
>
>> I noticed today that out of about 19 pages of issues, only the first 5
>> have "awaiting" labels. Would p
And this email was written when heading out the door, so sorry if came off
as me being short.
On Sat, Oct 7, 2017, 14:32 Brett Cannon, wrote:
> This off-topic for this thread. If you want to discuss adding support for
> another trigger phrase you can bring it up on core-workflow.
>
On Fri, 6 Oct 2017 at 15:50 Terry Reedy wrote:
> On 10/6/2017 5:29 PM, Brett Cannon wrote:
> > I noticed today that out of about 19 pages of issues, only the first 5
> > have "awaiting" labels. Would people object if I back-filled those open
> > issues lacking an &
On Fri, 6 Oct 2017 at 14:37 Donald Stufft wrote:
>
> > On Oct 6, 2017, at 5:36 PM, Alex Gaynor wrote:
> >
> > Can we please use a phrase for re-triggering a review that makes more
> sense like "I've updated the patch, please re-review", rather than magic
> inside baseball language?
> >
>
>
> +1
Ewa handle the updating, and since she lives in the States it's possible it
hasn't happened yet due to US Thanksgiving.
On Fri, Nov 24, 2017, 03:05 Antoine Pitrou, wrote:
>
> Hello,
>
> I forget... Who handles updating the Python CLA database?
> One of our contributors apparently signed the CLA
I just approve Ivan's subscription request to this list.
And I know it's late, but a resounding +1 to this happening!
On Wed, 6 Dec 2017 at 09:21 R. David Murray wrote:
> On Wed, 06 Dec 2017 08:43:56 -0800, Guido van Rossum
> wrote:
> > I think I figured it out -- I invited him to the python o
On Wed, 6 Dec 2017 at 15:17 Victor Stinner wrote:
> Hi,
>
> I wrote a quick & dirty parser to compute statistics on *new* CPython
> core developer per year using the following page as data:
> https://devguide.python.org/developers/
>
> 2007: 15
> 2008: 19
> 2009: 11
> 2010: 20
> 2011: 12
> 2012:
On Wed, 6 Dec 2017 at 10:25 Ethan Furman wrote:
> On 12/06/2017 09:43 AM, Victor Stinner wrote:
>
> > Congrats Cheryl!
>
> Possibly a dumb question, but is Cheryl on this list?
>
Nope, but that's because we have kept this list to only core devs and not
people who have triage powers on the issue
I have a subscription request to python-committers from Cheryl. Im planing
rejecting it since we have kept this list only to committees, but I didn't
want it to come off as rude when it happens.
I also don't know if we want a triage-only list.
On Sat, Dec 9, 2017, 05:13 Victor Stinner, wrote:
>
On Mon, 11 Dec 2017 at 10:56 Antoine Pitrou wrote:
>
> Hi Julien,
>
> (and welcome on this list)
>
> Le 11/12/2017 à 19:53, Julien Palard a écrit :
> >
> > Recovery codes are on the "something you have" side, they are not a
> secret,
> > they are a possession, so it's completly OK to keep your re
On Tue, Dec 12, 2017, 05:07 M.-A. Lemburg, wrote:
> I'm with David on this one. 2FA is good for admin accounts, but
> doesn't add much protection for regular committers. Think of what
> you're trying to protect against: git checkins are all audited and
> can easily be undone.
>
But David has an
Donald has always been our intermediary as he has connections over there.
Also realize that Circle CI came forward on the core-workflow mailing list
asking if we were willing to switch, but I didn't hear back after saying
what we would probably need to make the switch.
On Sun, Dec 31, 2017, 12:37
I just switched it on to help make sure we don't break on Windows just
before hitting beta. If it turns out AppVeyor isn't stable enough I will
switch it back off.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mai
lds (and perhaps 2.7) trigger two sequential AppVeyor
> jobs:
> https://ci.appveyor.com/project/python/cpython/build/3.6build10551
If the wait times become an issue for anyone then let me know and we can
re-evaluate the situation.
-Brett
>
>
> Regards
>
> Antoine.
>
&g
I can switch off the requirement that holds admins to having to pass the
same status checks as everyone else (there's still a big warning when you
exercise this power), that way you can override the merge if you want. Not
sure if you want to ignore the CI in that case as well.
On Mon, 22 Jan 2018
Done, making Nathaniel the 90th member of the current core team! He also
needs to send a subscription request for python-committers.
On Thu, 25 Jan 2018 at 09:24 Yury Selivanov wrote:
> Alright, it's decided! I now envy Nathaniel a bit, so many people +1-ed!
>
> I've added Nathaniel to devguide
I have removed your access on GitHub and unsubscribed you from
python-committers. Sorry to see you go, Xavier, but look forward to
continuing to work with you on PRs!
On Thu, 25 Jan 2018 at 04:29 Xavier de Gaye wrote:
> I have decided for personal reasons to stop contributing to CPython as a
> c
e didn't wait and we landed breaking
changes. So unless other people speak up that the delay is a hindrance I'm
inclined to leave it until we at least get past the beta.
-Brett
>
> Victor
>
> 2018-01-10 21:45 GMT+01:00 Brett Cannon :
> > I just switched it on to hel
On Fri, 26 Jan 2018 at 13:04 Ethan Furman wrote:
> On 01/26/2018 09:28 AM, Mariatta Wijaya wrote:
>
> > So when the original PR didn't have a news entry, what should I have
> seen to alert me to that?
> >
> > If a news entry is missing from the PR, the CI check at the bottom of
> the PR will
1 - 100 of 669 matches
Mail list logo
