[python-committers] Re: PSF hires first Developer-in-Residence (was: Re: Re: Call for resumes: Developer-in-Residence to support CPython)

lying the lessons they've already learned to the CPython experience) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to p

[python-committers] Re: core-dev chat

On Sat, 15 May 2021, 6:35 am Paul Moore, wrote: > On Fri, 14 May 2021 at 21:18, Senthil Kumaran wrote: > > > > In other words, this isn't a technology problem, it's a people > > > problem. > > > > Both. I didn't suggest this is technology problem. We, have to > > choose one as per majority

[python-committers] Re: Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642

On Tue, 9 Feb 2021, 8:18 am Terry Reedy, wrote: > > The one thing I think needs to be discussed and not been much, at least > not publicly that I have seen, is whether we really want to go down the > road of contextual keywords. There are some negatives as well as > positives. Just because the

[python-committers] Re: Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642

On Tue, 9 Feb 2021, 6:21 am Python Steering Council, < steering-coun...@python.org> wrote: > After much deliberation, the Python Steering Council is happy to announce > that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, > collectively known as the Pattern Matching PEPs. We

[python-committers] Re: metaclass names and backwards compatibility

I think you had good reason to call it EnumMeta though: to better distinguish "the enum meta type" (i.e. EnumMeta) from "enum types" (i.e. instances of EnumMeta). Cheers, Nick. On Sat, 23 Jan 2021, 9:17 am Ethan Furman, wrote: > The question: > >Can we change the name of classes if we keep

[python-committers] Re: 2021 Python Steering Council Election Results

Congratulations, all! Regards, Nick. ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message

[python-committers] Re: PEP 641: Using an underscore in the version portion of Python 3.10 compatibility tags

As the PEP notes, the PyPA devs already assumed this is what would happen for ambiguous version numbers, so it looks good to me. Cheers, Nick. On Thu., 22 Oct. 2020, 5:58 am Brett Cannon, wrote: > https://www.python.org/dev/peps/pep-0641/ (once the cron job runs) > > >

[python-committers] Re: Thank you Larry Hastings!

Thank you, Larry! Cheers, Nick. ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived

[python-committers] Re: Policy around compile-time flags in bugfix releases

Enabling that workaround for embedders using threads without coroutines while figuring out the real underlying contextvars issue seems like a reasonable change to make in the maintenance branches. Cheers, Nick. ___ python-committers mailing list --

[python-committers] Re: Possible bug in voting system ? (was: Re: Reminder to vote for the 2020 Steering Council)

marked as inactive that this was happening (as it had to be inferred from the absence of your name, rather than being called out as a list of voters that had been flagged as potentially inactive since the last voter roll was generated). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com |

[python-committers] Re: Nominations for the 2019 Steering Council Election are now open.

ted in my not being able to be as active and constructive a participant in the SC as I would have wished. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list -- python-committers@python.org To u

[python-committers] Re: [RELEASE] Python 3.8.0 is now available

Huzzah! Thank you to you and the rest of the release team for coordinating this, and to everyone that contributed changes and fixes :) Cheers, Nick. On Tue., 15 Oct. 2019, 6:24 am Łukasz Langa, wrote: > On behalf of the Python development community and the Python 3.8 release > team, I’m

[python-committers] Re: Currently working on the release of Python 3.8.0rc1

be > seeing RC1 out tonight. I've filed https://bugs.python.org/issue38326 as a release blocker, as I don't think we should be cutting RCs when changes have been made to a PEP-approved API without any pre-merge design discussion. Cheers, Nick. -- Nick Coghlan | ncogh

Re: [python-committers] [Steering-council] Re: Can we choose between mailing list and discuss.python.org?

On Tue., 12 Feb. 2019, 7:18 am Brett Cannon > > On Mon, Feb 11, 2019 at 10:26 AM Victor Stinner > wrote: > >> Le lun. 11 févr. 2019 à 18:58, Carol Willing a >> écrit : >> > PS Copying the steering council in case someone has a different view. >> >> So you chose a mailing list and not Discourse?

Re: [python-committers] Fwd: EPS: Announcing the Guido van Rossum Core Developer Grant

o handle the uncertainty associated with being accepted as a speaker, but then having to wait to see if their financial aid was approved before they could accept the speaking slot. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _

Re: [python-committers] Election: you can change your vote

preceding page with the final submit button). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

would need a group of people reviewing individual 3.6 pull requests to >> decide to pick them or not. I would volunteer to review these PRs and >> merge them. >> >> The idea isn't new, Nick Coghlan proposed a "ELPython" last year: >> >>https

Re: [python-committers] IMPORTANT: Missing Email Addresses for Governance Election Voter Roll

t in bugs.python.org (which is necessarily linked on GitHub usernames, as otherwise the CLA check wouldn't pass). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@

Re: [python-committers] Vote on governance will happen between Nov 16 - Nov 30

ly that a significant proportion of the folks voting will find any of them completely unacceptable) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.

Re: [python-committers] python-committers is dead, long live discuss.python.org

On Sat., 29 Sep. 2018, 7:40 pm Łukasz Langa, wrote: > > On Sep 29, 2018, at 09:53, Nick Coghlan wrote: > > Especially on the eve of critical governance discussions that will heavily > impact the future of python-dev. > > > Ironically it's the very gravity of those upcomi

Re: [python-committers] python-committers is dead, long live discuss.python.org

On Sat., 29 Sep. 2018, 11:19 am Barry Warsaw, wrote: > On Sep 28, 2018, at 17:45, Łukasz Langa wrote: > > > Do you use NNTP? Like with IRC, you won't find the next generation of > core developers on it. And no, there is no support for it in Discourse. > > > > We could probably figure something

Re: [python-committers] Python 4.0 or Python 3.10?

ers, but if we find one where it isn't, then we'd just specify a collation order to use for Python version comparisons) Cheers, Nick. [1] https://www.python.org/dev/peps/pep-0425/#python-tag -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _

Re: [python-committers] Python 4.0 or Python 3.10?

n "X.Y" separator, or stating that "X_Y" should be used when "XY" would be ambiguous), we can expect actually making such a release to find latent defects in assorted different pieces of software. However, unlike the 3.x compatibility breaks, adap

Re: [python-committers] [PEP 8013] The External Council Governance Model

gates out when it came time to end discussion of a proposal and make their decision (whether for or against) stick. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@

Re: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel

On Sat, 15 Sep 2018 at 05:28, Raymond Hettinger wrote: > > At the developer sprints this week, we collectively decided to grant core > committer status to Emily and Lisa. Congratulations, and welcome! Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane,

Re: [python-committers] Recent buildbot.python.org changes

On Sat, 15 Sep 2018 at 07:02, Zachary Ware wrote: > > Hi all, > > Most of my effort this week has gone into improving the state of > buildbot.python.org, which has largely gone into improving Buildbot > itself. [snip] Very nice! Cheers, Nick. -- Nick Coghlan |

Re: [python-committers] And Now for Something Completely Different

ying to tell the individual plants how to grow leaves and flowers :) [1] http://community.redhat.com/blog/2017/05/let-the-river-flow/ [2] https://community.redhat.com/blog/2017/05/seeds-of-community/ -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia __

Re: [python-committers] And Now for Something Completely Different

uld be similar. And I think that's inevitable in an environment driven primarily by volunteer and sponsored development: the time to pursue particular activities has to come from somewhere, and that's either going to be the intrinsic motivations of individuals donating their own time, or else the extrin

Re: [python-committers] An alternative governance model

ing any further syntax changes beyond PEP 572 to Python 3.9 or later. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] PEP stewardship delegation: the minimal change approach

On 14 July 2018 at 19:36, Paul Moore wrote: > On 14 July 2018 at 08:05, Nick Coghlan wrote: >> So stealing Brett's excellent suggestion of "Design Steward" as a >> BDFL-independent term for the current BDFL-Delegate role, a potential >> PEP 1 amendment fo

[python-committers] PEP stewardship delegation: the minimal change approach

esign complexity, rather than due to it being a particularly controversial decision on whether or not to do anything at all. Cheers, Nick. [1] https://www.python.org/dev/peps/pep-0001/#pep-review-resolution [2] https://www.pypa.io/en/latest/specifications/#proposing-new-specifications -- Nic

Re: [python-committers] Transfer of power

ithout the burden of always needing to be the ultimately responsible decision maker :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.

Re: [python-committers] Introduction - Pablo Galindo Salgado

definitely good to be careful, we also have lots of systems in place to help us correct course when we inevitably do make mistakes :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list py

Re: [python-committers] Changing commiter status (was: Missing In Action)

quest reactivation (likely just "Check the developer guide to ensure you're up to speed with any changes since you were last active, then past to python-committers requesting that your credentials be reactivated"). Cheers, Nick. -- Nick Coghlan | nco

Re: [python-committers] Core Dev Sprints

ld Microsoft swag ;) > I was going to suggest you ask the Azure dev advocates to come up with something involving their mascot Bit, and then I noticed the last entry on https://github.com/ashleymcnamara/Developer-Advocate-Bit#find-me-on-twitter :) Cheers, Nick. -- Nick Coghlan | nco

Re: [python-committers] Comments on moving issues to GitHub

On 3 June 2018 at 17:00, Nick Coghlan wrote: > I'll also email Maciej & EW Durbin ([1]) to see if they've had a chance to > discuss the rehosting plans for bugs.python.org yet. > The status update here is that Maciej has been bringing Ernest up to speed on the preparatory work tha

Re: [python-committers] Comments on moving issues to GitHub

he PSF's new Director of Infrastructure [2], who some folks may already know from his extensive work on PyPI and other parts of the PSF infrastructure, as well as chairing Python US in 2018/19 [2] https://twitter.com/EWDurbin/status/1001519029767561216 -- Nick Coghl

Re: [python-committers] number of active core devs [was: Comments on moving issues to GitHub]

ck. [1] https://www.openhub.net/p/python -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)

ng why I think it might be a release blocker and asking the RM to take a look it at The RM then makes their decision by either commenting to say they're accepting the issue as a blocker, bumping it down to deferred blocker (if they don't think it's a blocker *yet*), or else bumping it down to one o

Re: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions?

on-dev has also raised sufficient further concerns to push the whole concept back into python-ideas territory. (I do think the discussions have clarified the nature of the cases where the current lack of any form of inline binding support can be genuinely irritat

[python-committers] Welcoming Petr Viktorin as our newest core developer :)

, and this mailing list. Welcome, Petr! :) Cheers, Nick. P.S. When adjusting the nosy list on the issue tracker, you'll find there's also a new "extension modules" topic, which can be selected to subscribe both Petr and I to the issue :) -- Nick Coghlan | ncogh...@gmail.com | Brisbane,

[python-committers] Proposing Petr Viktorin as a specialist core developer

he's the current Python maintenance team lead at Red Hat), and he also has a lot of practical Python 2->3 porting experience (as a result of coordinating much of the migration effort for Fedora and RHEL, including leading the creation of https://portingguide.readthedocs.io/en/latest/index.html ) -

Re: [python-committers] Wanting to merge my first PR under github - a bit of advice

you looked for them :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Auto-merge the backport PR with one core dev approval and all passing CI

/cpython/pull/5547#event-1468940344 > Huzzah, thank you! Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-commit

Re: [python-committers] Auto-merge the backport PR with one core dev approval and all passing CI

me, as being able to do the backport PR reviews as soon as Miss Islington creates them means I'll still have the original review fresh in my mind. (I know I can theoretically do that now, but I currently tend not to look at the details of the backport PRs until the CI run is finished) Cheers, Nick. --

Re: [python-committers] cherry picking, miss islington, and generated files

at we don't backport to 3.7. Whereas the cherry picking just outright failed on 3.6 because the current state of the frozen importlib on that branch is different. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ pyt

Re: [python-committers] cherry picking, miss islington, and generated files

g on humans to notice those problematic cases, but we may be able to at least have CI fail if "make regen-all" actually changes any file contents for checked in files. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [python-committers] ssl module will require OpenSSL 1.0.2

(including Docker themselves) will also have a fair incentive to solve the problem (although in that case, their resolution might be "switch back to using OpenSSL given the improvement over the past couple of years"). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.c

Re: [python-committers] [Python-Dev] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

tep entirely. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.py

Re: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug)

ives closed so they're not available to search engines). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-

Re: [python-committers] RFC: Process to become a core developer

volunteers are mentoring and managing other volunteers, it's even easier for unconscious biases to come into play than it is in a more explicitly professional setting. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [python-committers] Official python-dev docker images

ainst the upstream builds becomes a first step in triage for problems encountered with redistributor builds: if a problem only shows up in the distro version, then distro specific patches would be the first place to look. Cheers, Nick. P.S. This thread would probably be better located on python-dev :)

Re: [python-committers] Promote Julien Palard as core developer

! As the saying goes, "For most users, if it isn't documented, it may as well not exist" :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org

Re: [python-committers] Adding Ivan Levkivskyi as a core committer

im completely. +1 from me - I found him very receptive to feedback and easy to work with when discuss his proposed changes to the runtime typing machinery. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ p

[python-committers] Mostly offline from December 10th through to January 1st

een around for a decade and a half, so I don't think anyone is really going to care all that much whether it gets fixed in 2018 or in 2019. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@

Re: [python-committers] [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

On 6 November 2017 at 02:02, Yury Selivanov <yselivanov...@gmail.com> wrote: > On Fri, Nov 3, 2017 at 11:30 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> The current lack of DeprecationWarnings in 3.6 is a fairly major >> oversight/bug, though: > &

Re: [python-committers] [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

7.2.1 20170915 (Red Hat 7.2.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> await = 1 >>> async = 1 >>> print(async, await) 1 1 So if we're going to go ahead with making them

Re: [python-committers] What is a CPython core developer?

f an existing core dev reviewing quite a few of a contributor's patches, and then asking if becoming a core developer themselves is a goal they've considered. There are some additional responsibilities listed at https://docs.python.org/devguide/coredev.html#responsibilities, but aside from the first

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

for an issue I filed, or I'm working on a separate change that would end up conflicting with their PR if I left theirs open. That way if they think of an alternative approach that they'd prefer to use, they can still just amend their existing PR and ask for an additional review, rather than ha

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

- we have a static set of machines that work through the merged commits. Cheers, NIck. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/

Re: [python-committers] New workflow - some questions

fference on the server side though - it's strictly about how the git client authenticates your identity with the server. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-commi

Re: [python-committers] Travis-CI compiles twice

y generating out-of-place and then doing either a rename (if the result changed), or deleting the new one (if it is the same as the original). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list pyth

Re: [python-committers] Dismiss review if a PR is modified

rently offer that (it doesn't allow self-review at all, not even to mark your own PRs as still requiring further changes). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-commi

Re: [python-committers] My (positive) feedback on the new CPython workflow

in addition to thanking the folks working on the migration and the associated automation, I'd also like to explicitly thank Mariatta, Terry, Zachary, and everyone else that has contributed to the git cheatsheet and other workflow documentation updates in the developer's guide. Cheers, Nick. --

Re: [python-committers] AppVeyor off?

send that back before (or in parallel with) scheduling the CI run itself. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/list

Re: [python-committers] [Python-Dev] New workflow change: Welcome to blurb

ay towncrier works, and we figure they're close enough in spirit that folks familiar with one won't have any problems adapting to the other. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing

Re: [python-committers] Revert changes which break too many buildbots

On 15 June 2017 at 19:35, Nick Coghlan <ncogh...@gmail.com> wrote: > On 15 June 2017 at 00:40, Victor Stinner <victor.stin...@gmail.com> wrote: >> A recent example is Nick Coghlan's implementation of the PEP 538: >> basically, it broke all buildbots...

Re: [python-committers] Revert changes which break too many buildbots

say "Hey, my availability is likely to be intermittent for a while, so the buildbot for may be unreliable until ". That way, other folks that care about the platform may be more alert to resolving platform specific issues during that time (and may even be able to take over the lead pl

Re: [python-committers] Revert changes which break too many buildbots

On 15 June 2017 at 23:38, Victor Stinner <victor.stin...@gmail.com> wrote: > 2017-06-15 5:31 GMT+02:00 Nick Coghlan <ncogh...@gmail.com>: >> For example, something that would be genuinely helpful would be a bot >> monitoring PR comments that could automate the "

Re: [python-committers] Revert changes which break too many buildbots

[2] https://bugs.python.org/issue30672 [3] https://bugs.python.org/issue30565#msg296006 [4] https://bugs.python.org/issue30647 -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.

Re: [python-committers] Revert changes which break too many buildbots

e change 2. Post a "BuildBot: test custom build" comment on the offending PR 3. Original PR author, committer, and anyone else interested continues the issue resolution process based on the specific links posted back by the helper bot Cheers, Nick. -- Nick Coghlan | ncogh...@gma

Re: [python-committers] Added a "sprint" label to GitHub

ded a comment with the sprint name. Cheers, Nick. [1] https://public.etherpad-mozilla.org/p/pycon-pune-2017-cpython-sprint -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.o

Re: [python-committers] Guide to pushing to submitters' repo?

.S. the "git pr" alias mentioned there is detailed a few entries earlier in the cheat sheet -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/ma

Re: [python-committers] Proposing Carol Willing to become a core developer

y so. :) Definite +1 from me (I was actually thinking of emailing Carol about the idea before I saw this thread) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org ht

Re: [python-committers] Github reviews are cannibalizing BPO

psf-proffers-payment-to-port-to-python.html I know at least one former upstream Roundup developer recently moved into freelance software development & consulting, so I'll chat to him to see if he has any suggestions for possible ways forward here. Cheers,

Re: [python-committers] Proposal for procedures regarding CoC actions

reported Code of Conduct concerns. Handling of the latter will remain with the PSF Board or their appointed representatives, independently of how we handle moderation of the development channels. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [python-committers] Github reviews are cannibalizing BPO

ing the latter relates to maintaining URL stability, avoiding breaking our own and third party integrations, preserving current email-based individual workflows, and maintaining a PSF controlled archive of significant design decisions, rather than any particular flaws in alternative issue trackers. Ch

Re: [python-committers] Github reviews are cannibalizing BPO

his (and more reliably than the nosy list on BPO, since it's based on the actual files touched by a PR). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org http

Re: [python-committers] cherry_picker.py updated

ps://github.com/python/core-workflow/issues/44) > > Added --abort/--continue options to address > https://github.com/python/core-workflow/issues/45 > > Lastly, I added --status option, which will just perform `git status` for > the cpython directory. Thank you for the enhancements!

Re: [python-committers] Regarding reviewing test cases written for tabnanny module

On 15 April 2017 at 03:15, Serhiy Storchaka <storch...@gmail.com> wrote: > On 14.04.17 17:02, Nick Coghlan wrote: >> That was exactly my reaction when Serhiy pointed it out - I started to >> argue the point, but then invalidated all my own arguments before >> actuall

Re: [python-committers] Regarding reviewing test cases written for tabnanny module

On 12 April 2017 at 01:57, Guido van Rossum <gu...@python.org> wrote: > On Tue, Apr 11, 2017 at 7:42 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> Since we do the squash & merge to get an atomic commit at the end, it >> doesn't make sense to do an

Re: [python-committers] Regarding reviewing test cases written for tabnanny module

is adequate.) > > Some of our core committers need to learn to do this :) Technically coming up with a meaningful message when committing patches isn't a new requirement, but I admit it's a lot easier to forget to clean things up when there's a b

Re: [python-committers] Proposal for procedures regarding CoC actions

Board), it would then be up to the *Board* to decide if it needed a formal process for delegating such discussions and decisions to a smaller group. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposal for procedures regarding CoC actions

would then mostly apply to the channel moderators responsible for enforcing those Rules for Active Participation, since CoC violations on the communication channels themselves would *also* break the suggested rules 1 & 2 above (by being both off-topic and disrespectful of readers time and e

Re: [python-committers] I have blocked Wes Turner from the Python org on GitHub

as those for email). If there was finer granularity available on GitHub, the suspension would presumably have only been from the core-workflow repo specifically, but that's not currently an available option. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _

Re: [python-committers] Is clang testing necessary?

On 26 March 2017 at 03:54, Antoine Pitrou <anto...@python.org> wrote: > > Le 25/03/2017 à 16:27, Nick Coghlan a écrit : >> >> However, from the point of view of making it easier for Windows devs to >> debug *nix debug errors, it probably makes more sense to use clang

Re: [python-committers] Is clang testing necessary?

n use gcc to do the coverage run. That setup would give: - all 3 default compilers running in CI (MSVC in Appveyor, clang for the main Travis tests, gcc for the coverage run) - Windows devs getting the friendlier clang error messages when they're trying to debug a cross-platform compilat

Re: [python-committers] 4 weeks with the new workflow: what needs changing?

what I actually want is for the current notifications to be more useful, mainly by including the GitHub PR URL, rather than the internal-to-roundup numeric PR ID. I'd just forgotten about them until Paul mentioned them, as they're not particularly useful righ

Re: [python-committers] 4 weeks with the new workflow: what needs changing?

ve that with a few robustness tweaks and a conflict-avoiding approach to handling Misc/NEWS it would be up to the task of generating the actual PRs as well. (The other side of the bot that actually handled the interaction with GitHub could presumably be modeled on the way the existing knights-who-say-

[python-committers] Recent updates to "make patchcheck"

ot;, the base branch is "/master" - otherwise it is "/X.Y" (also based on sys.version_info) Note that this works fine for "make patchcheck" (since it uses the just built Python to run Tools/scripts/patchcheck.py), but anyone running the tool directly rather than through the makef

Re: [python-committers] New ncoghlan-bpo-29537-NEWS branch?

On 10 March 2017 at 04:32, Brett Cannon <br...@python.org> wrote: > > > On Thu, 9 Mar 2017 at 04:07 Nick Coghlan <ncogh...@gmail.com> wrote: > >> On 9 March 2017 at 19:30, Victor Stinner <victor.stin...@gmail.com> >> wrote: >> >> Do we

Re: [python-committers] [Python-Dev] 3.6.1 release status and plans

ws is unexpectedly leaving the parent directory of the given directory or archive on sys.path when running directories and zip archives on other platforms). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mai

Re: [python-committers] Please Publicize your Github Membership for Python

/github.com/python/cpython/blob/master/.mention-bot (as Guido has) - if you want to find your own reviewers for your PRs, add yourself to the PR blacklist in the same file (as Benjamin has) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [python-committers] GitHub migration scheduled for Friday, Feb 10

Thanks Brett and everyone else for working on the > migration. Indeed, thank you! Getting from "Wouldn't it be nice if we had a more convenient workflow?" to actually having one is a major undertaking for a project of CPython's size and age, and y'all have managed to come together and actu

Re: [python-committers] New team member intro

oks like most folks still aren't too keen on filling that out at this point :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/l

Re: [python-committers] Pace of change for Python 3.x

ted part-time contract role for X months to facilitate issue triage, patch reviews, and mentoring of potential new core developers" The latter motivation is about supporting the community and facilitating its growth, which is entirely in line with the Foundation's public interest mission. Cheers, Nic

Re: [python-committers] Proposed new core developer -- Mariatta Wijaya

ould work. That would be pretty similar to the way things worked when I recommended Yury for commit privileges - at the start, the only thing that changed was that the final step in the review process changed from "wait until I find time to commit the change" to "looks good to m

Re: [python-committers] Pace of change for Python 3.x

development team: http://www.activestate.com/company#careers -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x

help the PSF judge whether or not the grant was a success). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python

Re: [python-committers] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

On 22 Jan 2017 11:26 pm, "Paul Moore" wrote: One question (and apologies if this has been discussed on another list somewhere) - my biggest bottleneck is the sheer number of python-bugs emails, and the difficulty of identifying ones I can contribute. Will we be moving to

  1   2   3   >