[python-committers] Re: Proposed tiered platform support

[Zachary Ware]

On Fri, Mar 11, 2022 at 7:45 AM Marc-Andre Lemburg  wrote:
> If there are people in the community who wish to provide support for
> these platforms, I don't see a reason not to keep them in a tier 4.
> Such platforms would not be supported by the core team and don't
> necessarily need a buildbot (even though it would be good to have them).
>
> I find it problematic that the way Brett has written the proposal essentially
> means that we will not accept any PRs to help support platforms which
> are not listed in the tables. Could be that I misinterpreted his writeup,
> though.
>
> Esp. Android and possibly iOS are platforms which Python should be
> targeting in the future, since the story for Python on those platforms
> currently is pretty. We shouldn't make it harder to eventually gain
> such support and hopefully find new core devs who can maintain them
> to become fully supported.

As I understand it, the idea here is that if there is no core dev for
a platform, it's not actually supported in a practical sense
regardless of our official policy or lack thereof.  The policy Brett
is proposing just makes that explicit and gives us something to point
to when someone comes up with a patch to support PDP-11 or when
someone's patch for Android breaks Windows.  I don't think we'll wind
up with tier support police; if a core dev wants to take
responsibility for a patch for a platform that is not tier 3 or above
they can still do that, but if it breaks things for a supported
platform it will be reverted.

If there is serious support for a non-tiered platform, all it takes is
a buildbot and either an existing core dev to sign up to be the
maintainer or for us to vote in a maintainer, and then it can be a
tier 3 platform.  If there's not someone actively maintaining it and
the tests regularly being run on it, we can't realistically claim to
support it anyway.

I don't see much value in a tier 4: all other platforms that aren't
tier 3 or above are tier 4.  We could link to a wiki page for where
one might find links to support communities for non-tiered platforms,
but I expect such a list would bitrot at a rate that makes it not
worth including in the official tier list, whether by those
communities fading away or the platform being promoted to tier 3.


On Thu, Mar 10, 2022 at 5:36 PM Brett Cannon  wrote:
> Tier 1
> ==
>
> - `Test suite failures 
> `__
>  block releases.
> - Changes which would break the ``main`` branch are not allowed to be merged;
>   any breakage may be reverted immediately.
> - All core developers are responsible to keep these platforms working.
> - Promotion of this tier requires consensus/SC approval.

Should tier 1 require pre-merge CI?  We can currently do that, but
promoting a platform that's not provided by GHA could require
significant workflow changes.

> - Must have a stable buildbot.

I have concerns about the term "stable buildbot".  Until now, the
"stable"/"unstable" tags on buildbots have been the closest thing
we've had to a platform support policy and we've treated failures on a
"stable" buildbot to be release blockers (for the most part).  With a
proper platform support policy, "stable"/"unstable" should become a
description of the reliability of the particular worker machine to
provide an accurate representation of the state of the tests on the
platform rather than whether the tests usually pass, but I'm worried
about confusion from the changing meaning of those labels.
___
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 at 
https://mail.python.org/archives/list/python-committers@python.org/message/I6OHDE5OAK3OIF7ZPRHK573H4YIZ5EOM/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Dennis Sweeney is now a member of the Python Triage team

[Zachary Ware]

Hi all,

Just a quick note to mention that Dennis Sweeney (CC'd) has been added
to the Python Triage team:
https://github.com/python/core-workflow/issues/412.  Dennis has
already been responding to new issues, and the newly added permissions
will enable better responses and corrections to issue/PR metadata.

Welcome, Dennis!
___
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 at 
https://mail.python.org/archives/list/python-committers@python.org/message/YSLNWZHDJK63HH4X4NI4LG2SN3DCCDPK/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Vote to promote Ammar Askar

[Zachary Ware]

Hi all,

Pablo and I have started a poll to promote Ammar Askar as a core
developer.  Further details and the poll can be found here:
https://discuss.python.org/t/vote-to-promote-ammar-askar/9779

Thanks!

Zach
___
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 at 
https://mail.python.org/archives/list/python-committers@python.org/message/FIN53BCF43STEMPMIUZQ26EHPJ3EGJ4V/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Delete bpo spammer user

[Zachary Ware]

On Fri, Jul 9, 2021 at 2:27 PM Terry Reedy  wrote:
>
> One of the bpo admins should delete bpo user skoolbeep/Spammer 'Spammer'
> is the 'real name'!
> https://bugs.python.org/user?username=skoolbeep==&%40action=search
> see https://bugs.python.org/issue44550

I'm the one who set the 'real name' on that user as a warning to
others, and also removed the "User" role from the account such that
they should no longer be able to comment or do anything at all on
bugs.python.org with that account.  Deleting it at this point would
allow them to re-register with the same email address.

There are a few other similar accounts, see
https://bugs.python.org/user?username==Spammer=&%40action=search
(one of those I messed up a bit by actually changing the email
address, which basically just made it a dead account that's no longer
tied to the email address, leaving the spammer free to create a new
account with that address).

I'm not sure what I've been doing for these is the *best* course of
action, but it seems to have been relatively effective at stopping
those particular accounts from spamming.

-- 
Zach
___
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 at 
https://mail.python.org/archives/list/python-committers@python.org/message/2IW6USFY5OHPKSC2LCCMMR6PVIVCOCOS/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Commits are no longer noted in bro issues

[Zachary Ware]

On Mon, May 17, 2021 at 4:58 PM Victor Stinner  wrote:
>
> Any update on this issue? Nobody recalls what code and service sends a
> comment to bugs.python.org when a commit is merged?

I might have found it; I at least opened
https://github.com/psf/bpo-roundup/pull/1 against what I found :)
___
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 at 
https://mail.python.org/archives/list/python-committers@python.org/message/2US6PJQTNUS3NOYZV4AIONLFYSAJE5LX/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Commits are no longer noted in bro issues

[Zachary Ware]

On Wed, May 12, 2021 at 9:23 AM Guido van Rossum  wrote:
> (Could it have to do with the master->main move?)

I think this is likely; we do still get messages from backport PRs.
I'm not sure what service is actually creating the messages, though.

-- 
Zach
___
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 at 
https://mail.python.org/archives/list/python-committers@python.org/message/2OWKEPM7GMR6EZMQCQGLKBLFVNXEHWPS/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

[Zachary Ware]

On Tue, Apr 6, 2021 at 9:36 AM Victor Stinner  wrote:
> I'm getting more and more email notifications when a commit contains
> my GitHub handle ("@vstinner"). For example: "Automerge-Triggered-By:
> @vstinner".

Yes, this is a pretty substantial failing of GitHub for popular projects :(

> But the problem is that the "automerge" labels uses
> "Automerge-Triggered-By: @vstinner" syntax. Maybe a small enhancement
> would be to use ""Automerge-Triggered-By: vstinner" syntax instead
> (avoid the @).

This is already done; see
https://github.com/python/miss-islington/commit/334c817cecf6c5c7f074ec7dbbad89d491b42f1a
(we now use `GH:vstinner` to keep it clear that it's a GitHub handle
without triggering GitHub's automatic linking/mentioning).

> Some developers put my handle in a commit message since it becomes the
> PR descriptor and sends ping me by email. But then my handle lands
> into the merged commit message, like:
> ...
> I'm not asking you to stop mentioning me. I'm just asking for help how
> to filter these notifications?

This is one of the several reasons that I don't like using the PR
description as the commit message when using auto-merge :).  I still
think we ought to require a new comment with a special marker to
contain the commit message.  I haven't found time or motivation to
actually try to make this change, though.

That change wouldn't help with existing messy commits, though, and
those keep popping up when someone does something weird with their
fork, like rebasing one stable branch on another.  I'm afraid I don't
have a good solution for that that doesn't risk masking the messages
you might actually want to see :(
___
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 at 
https://mail.python.org/archives/list/python-committers@python.org/message/WDPQ5I6NBT6IRDKA4WQPVEWHQIUTPHJ7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: MSDN Subscription renewals

[Zachary Ware]

On Thu, Aug 13, 2020 at 12:29 PM Steve Dower  wrote:
> While most of the tooling necessary for working on CPython is freely
> available (as Visual Studio Community), this will also include OS images
> and Azure credits.

For reference, the Azure credit has been enough to me to run a Windows
8.1 buildbot for the past several years at no cost to me.

> Historically, Brian Curtin has helped out by collating our details and
> submitting the request, but now it's being passed over to me (since I
> can more easily track any internal changes).

Many thanks to Brian for taking care of this for many years and to
Steve for picking it up from here :)
___
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 at 
https://mail.python.org/archives/list/python-committers@python.org/message/VCUQPNG4DHXQJPT73SMZ4TZENKNK6DCI/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Make AppVeyor CI non-mandatory during the CPython sprint?

[Zachary Ware]

On Mon, Sep 9, 2019 at 4:51 PM Victor Stinner  wrote:
> Hi,
>
> I see a high activity on pull requests on the CPython project, likely
> because of the CPython sprint. Sadly, the AppVeyor is still slow and
> still has only 2 jobs in parallel.
>
> Would it be possible to make the AppVeyor job non-mandatory to allow
> to merge a PR faster? If it's configurable per branch, it would be
> nice to do this change for 2.7, 3.7, 3.8 and master branches.

I'm in favor of this, though we should perhaps just switch from
AppVeyor to Azure as the required check.  Azure seems to have been
stable enough, and is certainly faster than AppVeyor.  I wouldn't much
like to have no Windows build required in pre-merge CI.
___
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 at 
https://mail.python.org/archives/list/python-committers@python.org/message/55JOCR5CRORUJUCLG2WZLIQHICO5GOYL/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Welcome Abhilash Raj to the Python core team!

[Zachary Ware]

On Tue, Aug 6, 2019 at 4:20 PM Brett Cannon  wrote:
> Assuming I didn't mess anything up, Abhilash is now set up!

Welcome, Abhilash!
___
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 at 
https://mail.python.org/archives/list/python-committers@python.org/message/BOIWQ37N2R3GIE4YO4VESHRMJHXWYRSI/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Hello

[Zachary Ware]

On Mon, Apr 15, 2019 at 6:10 AM Stephane Wirtel  wrote:
> Hello everyone,

Welcome aboard, Stephane! :)

-- 
Zach
___
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/

[python-committers] bpo triage privileges for Karthikeyan Singaravelan

[Zachary Ware]

On the recommendation of Ammar Askar and with Serhiy's endorsement on
Zulip [0], I've given Karthikeyan Singaravelan (CC'd) triage
privileges on bugs.python.org.

Karthikeyan, please use your new-found powers for good, and don't
hesitate to ask for guidance if you need it.  Keep up the good work,
and thank you!

[0] 
https://python.zulipchat.com/#narrow/stream/116501-workflow/subject/bug.20tracker.20triage.20permissions
-- 
Zach
___
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/

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

[Zachary Ware]

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.  Here are the relevant highlights:

- Anyone can now log into buildbot.python.org via GitHub by clicking
the 'Anonymous' dropdown in the upper right corner, then 'Login with
GitHub'.  The first time, GitHub will ask you for approval;
subsequently you'll just be logged right in.

- Stopping builds and triggering rebuilds is now restricted to members
of the `python-core` team and the "owner" of a build.  I've not had
opportunity to test whether the author of a commit actually qualifies
as the "owner" or if only the committer does, but if anyone runs into
trouble with it please open an issue on the buildmaster-config repo.

- Disabling/enabling schedulers is now restricted to members of the
`python-release-managers` team.  We had an issue some months ago where
someone had apparently disabled the scheduler for one of our branches,
resulting in no builds on that branch for several days before we
noticed.  That shouldn't happen again!

- Buildbot now reports results from our stable builders on each tested
commit.  For now, we're still only running tests post-merge, so you
won't see new status checks on PRs, but you can find results on
https://github.com/python/cpython/commits/

Let me know if any of these changes negatively impact you, or if you
have suggestions for further improvement.

Regards,
-- 
Zach
___
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] New core developers: Lisa Roach and Emily Morehouse-Valcarcel

[Zachary Ware]

On Fri, Sep 14, 2018 at 12:28 PM Raymond Hettinger
 wrote:
> At the developer sprints this week, we collectively decided to grant core 
> committer status to Emily and Lisa.

Congratulations and welcome, Emily and Lisa!

-- 
Zach
___
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: an explicit, time-limited moratorium on finalizing any governance decisions

[Zachary Ware]

+1

--
Zach
(On a phone)

On Wed, Jul 18, 2018, 21:54 Ethan Furman  wrote:

> On 07/18/2018 07:36 PM, Nathaniel Smith wrote:
>
> > [tl;dr: We need some ground rules, because uncertainty makes it hard
> > to think straight. But if we get sucked into a complicated meta-debate
> > about the ground rules then that defeats the purpose. My proposal for
> > a Minimum Viable Ground Rule: let's all agree not to finalize any
> > governance decisions before October 1.]
>
> +1
>
> --
> ~Ethan~
>
> ___
> 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/
>
___
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] Introduction - Pablo Galindo Salgado

[Zachary Ware]

On Wed, Jun 20, 2018 at 10:30 AM, Pablo Galindo Salgado
 wrote:
> Hi everyone,

Hi Pablo, welcome, and congratulations!

> I will do so with extra care so nobody will be disappointed for this
> decision.

Because you're human, you're going to screw something up at some
point, just as each of us has done already and will do again :).
Don't worry about it too much; just try to exercise good judgement,
accept (hopefully constructive) criticism, try to fix things when you
do break them and ask for help when you can't do it yourself.  And
remember to have fun.  After all, we're all volunteers; why are we
doing this if we're not enjoying it?

-- 
Zach
___
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] Wrongly stopping merges discourages merging.

[Zachary Ware]

Hi Terry,

I have an email going out to AppVeyor with you CCed, we'll see what
kind of response we get (probably tomorrow).  In the meantime, I'll
look into disabling largefile tests, or test_mmap specifically on
AppVeyor to see whether that helps the situation.

On Sun, Jun 3, 2018 at 3:23 PM, Terry Reedy  wrote:
> When we used hg, core dev committers could actually commit to the repository
> when they judged it appropriate.  When we moved to github, Brett, with
> whoever's approval, decided that we should no longer be trusted to make
> commits without approval of a couple of mindless robots.  However, the
> premise that the robots should be trusted is false.  So I again request that
> there be a manual override for when the robots are obviously giving false
> failures.
>
> Exhibit 1. For at least a couple of weeksin may, faults in the asyncio test
> (and another) caused the asyncio test to randomly fail about half the time.
> With one retest, each CI bot failed about 1/4 the time.  At least one bot of
> the two bots failed about 1/2 the time.  The AppVeyor queue ballooned.
>
> One could decrease the frustration and time to success (but only partly)  by
> only re-starting the bot that failed.  Doing so for Travis is fairly easy.
> Doing so with AppVeyor is obscure and error prone.
>
> I twice requested that the randomly failing tests be disabled.  Victor said
> he wanted to keep monitoring what they did.  I think he overly discounted
> the pain and frustration of having good merges blocked.  I think either 1)
> bad tests should be disabled, or 2. the CI code should be able to ignore
> failures by bad tests, or 3. responsible core devs should be able to.
>
> Exhibit 2. AppVeyor is badly broken.
>
> This morning Cheryl Sabella submitted a nice patch fixing an annoying
> behavior of IDLE's editor/shell/output windows.  The CI tests passed, the
> patch worked great, it only needed expansion of the placeholder blurb.  I
> was really excited.
>
> With some trepidation, I made the edit.  Unfortunately, both CI bots rerun
> the code tests even when the code is unchanged.  Blurb edits should be
> treated as doc-only changes, with only the blurb rechecked.
>
> My trepidation turned out to be well-founded.  My excitement is gone. After
> an error, AppVeyor just quit without reporting any failure cause.
> https://ci.appveyor.com/project/python/cpython/build/3.8build16869
>
> Since then, there have been 2 successes and 7 similar unexplained failures.
> https://ci.appveyor.com/project/python/cpython/history
> https://ci.appveyor.com/project/python/cpython/build/3.6build16871/job/c2q80njh9clnfgjt
> https://ci.appveyor.com/project/python/cpython/build/3.8build16872
> https://ci.appveyor.com/project/python/cpython/build/3.7build16873
> https://ci.appveyor.com/project/python/cpython/build/3.8build16874
> https://ci.appveyor.com/project/python/cpython/build/3.6build16876/job/t9nyt59wkwcn68nk
> https://ci.appveyor.com/project/python/cpython/build/3.8build16877
> https://ci.appveyor.com/project/python/cpython/build/3.8build16878
>
> The last is my restart.  The time wasted by this broken blockbot is time not
> spent doing something useful.  I would really like to have this patch in the
> .rc in a week -- along with a few others that should follow.
>
> Guido once asked what is off-putting about being a core developer.  This is
> one thing.
>
> Terry Jan Reedy
> ___
> 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/



-- 
Zach
___
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] Can I just rerun a test on AppVeyor?

[Zachary Ware]

On Thu, May 17, 2018 at 8:09 PM, Terry Reedy  wrote:
> I can restart a test on just Travis when AppVeyor (and now MSTS) all passed.
> But for the last few hours, test_async has failed 1/4 to 1/3 of the runs.
> This means that test_async failed twice, so I suspect that it actually fails
> about half the time.  A connection error seems to be the main culprit.
>
> I could not find a rebuild button on the AppVeyor page, even after
> connecting my github account with AppVeyor.  I ended up closing and
> reopening, but this wastes resources on Travis and now MSTS.
>
> On the rerun, it failed the first time and then passed on the rerun

It is unfortunately non-obvious that you have to choose "python"
rather than your own GitHub username after clicking the "login via
GitHub" button, but after logging in that way you should have a
"Re-build PR" button at the top of the page of any PR build.

I'm not certain that permissions were set correctly before, but they
definitely should be now.

-- 
Zach
___
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] Issues with hundreds of commits being opened and closed -- what's going on?

[Zachary Ware]

On Thu, Feb 15, 2018 at 6:21 PM, Guido van Rossum  wrote:
> Occasionally I receive a sequence of emails from GitHub where a PR is
> requesting my review by some user, the-knights-who-say-ni responds with a
> CLA request, and then Bedevere closes it, without comment. Latest example:
> https://github.com/python/cpython/pull/5693
>
> This seems to be some kind of user error -- the GitHub description is
> typically something like " wants to merge 398 commits into master from
> 3.5". But this happens so frequently I would like to prevent this user error
> from happening in the first place.
>
> Does anyone understand what these users are doing that causes such PRs to be
> created?

This is because GitHub allows anyone logged into the site to click the
"New pull request" button on the branches page
(https://github.com/python/cpython/branches).  I reported this to
GitHub several months ago and the last word was that they were
"discussing it internally"; I'll bug them about it again.

-- 
Zach
___
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] cherry picking, miss islington, and generated files

[Zachary Ware]

We already have Travis checking 'make regen-all' and 'make clinic'
(assuming it's working correctly).

--
Zach
(On a phone)

On Feb 4, 2018 9:09 PM, "Nick Coghlan"  wrote:

On 4 February 2018 at 00:54, Barry Warsaw  wrote:
> On Feb 2, 2018, at 20:40, Mariatta Wijaya 
wrote:
>>
>> Sure, I sort of asked this in the past: what are the generated files,
how to identify them, is there a pattern?
>
> I’m not sure there’s going to be a pattern so much as a list of such
files.

- all C files may potentially contain Argument Clinic headers that
modify them in place
- build input files (configure.ac, etc) may change the other build artifacts

At the moment, I think we're still relying 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
___
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/
___
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] AppVeyor builds broken

[Zachary Ware]

On Thu, Dec 14, 2017 at 10:27 AM, Antoine Pitrou  wrote:
>
> Hello,
>
> It seems AppVevor builds (and generally Windows builds) have been broken
> for some time with a failure in test_distutils:
> https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.9471#L2040
>
> ==
> ERROR: test_get_exe_bytes 
> (distutils.tests.test_bdist_wininst.BuildWinInstTestCase)
> --
> Traceback (most recent call last):
>   File "C:\projects\cpython\lib\distutils\tests\test_bdist_wininst.py", line 
> 24, in test_get_exe_bytes
> exe_file = cmd.get_exe_bytes()
>   File "C:\projects\cpython\lib\distutils\command\bdist_wininst.py", line 
> 361, in get_exe_bytes
> f = open(filename, "rb")
> FileNotFoundError: [Errno 2] No such file or directory: 
> 'C:\\projects\\cpython\\lib\\distutils\\command\\wininst-14.12.exe'
> --

See https://bugs.python.org/issue32302.  Subsequent builds should
succeed; if you need to restart a build on a PR, you have two options.
The simpler, noisier option is to close and reopen the PR.  Otherwise,
log into AppVeyor using GitHub OAuth, which should give you the option
to log in as "python".  Then navigate to the build you want to restart
and click "Re-build PR".

-- 
Zach
___
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] Flood of Github review mails?

[Zachary Ware]

Being added to the team caused me to be 'watching' the repo again, even
though I'd previously 'unwatched'. Paul, you may need to unwatch again as
well.

--
Zach
(On a phone)

On Aug 20, 2017 09:28, "Steve Dower"  wrote:

> We created a Windows team on github and signed it up for notifications of
> changes to PC, PCBuild and the installer folders. If the notifications are
> for files in those folders, that’ll be it. (Though I haven’t noticed any
> similar increase, so it may be something else.)
>
>
>
> Feel free to remove yourself from the team if it looks like that’ll help.
>
>
>
> Top-posted from my Windows phone
>
>
>
> *From: *Paul Moore 
> *Sent: *Sunday, August 20, 2017 6:08
> *To: *python-committers 
> *Subject: *[python-committers] Flood of Github review mails?
>
>
>
> I've just recently (within the last week I guess) started getting a
>
> large number of additional mails from github. For example, I'm getting
>
> notifications on https://github.com/python/cpython/pull/3066 which I
>
> haven't commented on or been mentioned in, nor am I nosy on the
>
> underlying bug.
>
>
>
> What's changed to cause this to start happening, and how do I make it
>
> stop? I've nowhere near enough time to review all the mails I'm now
>
> getting, and I'd rather avoid them so I don't miss notifications that
>
> I *do* need to see :-(
>
>
>
> Thanks,
>
> Paul
>
> ___
>
> 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/
>
>
>
> ___
> 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/
>
>
___
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] Travis-CI compiles twice

[Zachary Ware]

On Mon, Jul 24, 2017 at 3:55 AM, Victor Stinner
<victor.stin...@gmail.com> wrote:
> Zachary Ware explained me once that "make regen-all" should be run
> after "make", but I don't recall why :-)

The real kicker is `make clinic`, which fails unless done after `make
all`.  I'd be all in favor of fixing that (and adding `clinic` to
`regen-all`), but if that turns into a bigger-than-expected project I
also like Victor's idea of doing `make regen-all clinic` in a separate
GCC job.

-- 
Zach
___
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] How do I kill an AppVeyor build?

[Zachary Ware]

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.appveyor.com/gitHubTeams while logged in as 'python'.

That looks like the right place to make the changes, anyway; I haven't
tried to actually make any :)

-- 
Zach
___
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] Promote Julien Palards as Committers on docsbuild-scripts

[Zachary Ware]

+1

--
Zach
(On a phone)

On Jun 13, 2017 02: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/JulienPalard

Thanks to the migration to GitHub, we are now able to give access to
someone to a single repository, no?

He wrote the documentation translation which has been accepted by Guido in
May:

  https://www.python.org/dev/peps/pep-0545/

Julien needs to make minor changes to the documentation build system
to support translations, see his pull request:

  https://github.com/python/docsbuild-scripts/pull/11

The Git repository of docsbuild-scripts has 41 commits and 7 of them
(17%) are already written by Julien :-)

Victor
___
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/
___
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] Windows License for a core dev

[Zachary Ware]

On Thu, Jun 8, 2017 at 11:39 AM, Mariatta Wijaya
 wrote:
>  and will it work with VirtualBox on mac?

Yes, very well :).  That (and Azure, to which you get a monthly credit
with MSDN subscription) is the only way I've been able to run Windows
for some time now.

-- 
Zach
___
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] Appveyor tests failing for CPython?

[Zachary Ware]

On Mon, May 29, 2017 at 9:09 AM, Alex Gaynor  wrote:
> Hi all,
>
> It looks like appveyor tests are currently failing on all builds (something
> about UNC paths + imports). Was appveyor enabled recently, or did the test
> regress?

AppVeyor has been enabled for some time, but is not (yet) required.
It's possible that something has regressed, but it looks kind of like
AppVeyor changed something in the environment, particularly since all
of our Windows buildbots are fine.

-- 
Zach
___
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] Guide to pushing to submitters' repo?

[Zachary Ware]

On Thu, May 25, 2017 at 6:27 AM, Antoine Pitrou  wrote:
>
> Le 25/05/2017 à 15:06, Nick Coghlan a écrit :
>> On 25 May 2017 at 18:01, Antoine Pitrou  wrote:
>>> Did someone manage to make this work?  Can they post the entire
>>> instructions they used? (including local branch setup)
>>
>> The minimal set of instructions some of us worked out are at
>> https://docs.python.org/devguide/gitbootcamp.html#editing-a-pull-request-prior-to-merging
>> (the initial draft was longer, but patch review found a few
>> opportunities for simplification)
>
> Thank you.  Is it possible for the "git pr" alias to also edit the
> branch tracking information?  Currently I get:
>
> (master)$ git pr 1785
> Depuis https://github.com/python/cpython
>  * [nouvelle référence] refs/pull/1785/head -> pr_1785
> Basculement sur la branche 'pr_1785'
>
> (pr_1785)$ LANG=C git pull
> There is no tracking information for the current branch.
> Please specify which branch you want to merge with.
> See git-pull(1) for details.
>
> git pull  
>
> If you wish to set tracking information for this branch you can do so with:
>
> git branch --set-upstream-to=/ pr_1785

Unfortunately, GitHub does not allow pushing back to refs/pull/*.  To
get it to set you up to push back to the contributor's repo, you'd
need to provide the contributor's name and branch name, which is much
less convenient if you're just looking to try out a patch locally
without intending to push anything back.  If I can figure out a good
second alias for that, I'll be sure to share it.

You may be interested in the `hub` tool, which has a command for
'check out this PR and set up a remote for it' (though I can't
remember what it is at the moment).

-- 
Zach
___
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] Proposing Carol Willing to become a core developer

[Zachary Ware]

On Tue, May 23, 2017 at 11:15 AM, Brett Cannon  wrote:
> 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 Carol, she basically knows our developer
> workflow better than most of us. :) ; she's very active on the devguide and
> core-mentorship. Carol has also attended the PyCon US language summit two
> years in a row as a representative for the Jupyter project. She is actually
> so good with new people that she managed to get my wife to make her first
> open source contribution (something I never managed to do).
>
> As usual, if you support/object to this idea, please say so. :)

+1

-- 
Zach
___
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] 4 weeks with the new workflow: what needs changing?

[Zachary Ware]

On Fri, Mar 10, 2017 at 4:13 PM, Brett Cannon  wrote:
> Requiring Travis to pass (I really don't want to turn this off as we already
> had a broken build when I temporarily turned it off at someone's request
> when Travis was backed up from the AWS S3 outage; I also don't plan to make
> AppVeyor required unless there's a way to make it be skipped for doc-only
> changes)

See GH-611.  I hadn't actually thought about that yet, but it turns
out to be pretty easy.

Also, I'm for keeping the Travis requirement, and also requiring
AppVeyor once we've ironed out some flaky tests.

> Cherry-picking working out? (We can go back to forward merging if people
> really want to, but I think long-term cherry-picking will allow for more
> automation)

Right now, cherry-picking is very annoying but I'm not sure that
merging would be much better with the PR requirement.  I'm looking
forward to automation!

> Along with that, are the labels for cherry-picking working out? (Some devs
> seem to like using title labels like `[3.6]` to flag cherry-picks so it's
> more obvious in emails so I don't know if the labels are really that useful)

I've considered whether I'd prefer having separate 'cherry-pick',
'needs backport', and 'x.y' labels rather than 'cherry-pick for x.y'
and 'needs backport to x.y'.  The separate 'x.y' labels would be
useful for issues that only pertain to a particular branch, but
requires selecting two separate labels when marking a PR as a
cherry-pick.  I'm not sure which I would actually prefer, I'm just
throwing the idea out there.

> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
> at https://github.com/facebook/mention-bot)

I think so, it has prompted me to give a quick review on a couple of
PRs.  It is occasionally annoying, but it's not hard to ignore.  I can
see how it would be *very* annoying for anyone who has touched large
swaths of the codebase, though.  If there's a way to make it opt-in,
perhaps we could give that a spin?

> Anything to tweak about the coverage bot and reports? (Our config is at
> https://github.com/python/cpython/blob/master/.codecov.yml and docs at
> https://docs.codecov.io/docs/codecov-yaml)

I haven't been noticing much of anything from the coverage bot since
we disallowed its comments.

Overall, I'm positive on the move.  Thanks for continuing to shepherd
the migration, Brett!

-- 
Zach
___
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] Is it just me or is the tip broken at the moment?

[Zachary Ware]

On Thu, Jul 7, 2016 at 11:03 AM, Steven D'Aprano  wrote:
> I'm wondering if I've broken something at my end, or if everyone is
> seeing the same error.

Works fine for me.  Have you rebuilt since pulling?  If a simple
'make' doesn't do it for you, try an hg purge before redoing configure
and make.  If you don't have the purge extension enabled, you can
enable it for one command like so: `hg --config extensions.purge=
purge --all`.  Note that `hg purge --all` will remove all untracked
files, so be sure you don't have any stray files in the repo that you
want to keep.

-- 
Zach
___
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] Promote Xavier de Gaye as a core developer

[Zachary Ware]

On Fri, May 20, 2016 at 3:53 PM, Victor Stinner
 wrote:
> I propose to promote Xavier de Gaye as a Python core developer.

I've had a few interactions with Xavier, all of which were positive.
+1 from me.

-- 
Zach
___
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/

[python-committers] The state of our copies of libffi (was: Redoing the C API?)

[Zachary Ware]

On Thu, Mar 3, 2016 at 12:38 PM, Brett Cannon  wrote:
> [...] the maintenance issue we have with ctypes (or at least that's
> my hang-up with it). I think we still have not figured out what code we have
> patched and so no one has been willing to update to a newer version of
> libffi. I think Zachary looked into it and got some distance but never far
> enough to feel comfortable with trying to update things.

Since I've been invoked, I'll try to explain our libffi situation as
far as I understand it.  This is just a history lesson, I don't really
have an opinion on what should be done with it.  I will opine that we
have some seriously old unmaintained code here, and the whole libffi
situation in cpython is far more complex than is ideal.

We actually have four separate copies of libffi:

Modules/_ctypes/libffi: This is a mostly-vanilla copy of libffi-3.1
(released 19May2014), lightly patched according to
Modules/_ctypes/libffi.diff.  This one is used for any non-OSX posix
build that doesn't use `--with-system-ffi`.  doko has done a pretty
good job keeping this one relatively up to date.

Modules/_ctypes/libffi_osx: This is a "lightly patched" copy from
somewhere before libffi-2.0, probably.  It has barely been touched
since 2009.  I've been given to understand that it has modifications
necessary to allow building fat binaries on OSX (Ned or Ronald would
know better than I), but I don't know if such modifications may have
made it upstream since pre-2.0.  This one is used for all OSX builds
that don't use `--with-system-ffi`.

Modules/_ctypes/libffi_msvc: This is a heavily patched copy from
27January2004 and is used for all Windows builds.  The patches include
additional functionality, namely
(IIRC) returning the number of arguments expected when calling a
foreign function with the wrong number of arguments to allow ctypes to
raise a ValueError instead of crashing.  I'm fairly certain those
modifications have not been even submitted upstream, and the
intervening twelve years (and my utter lack of experience working with
asm) scare me away from trying to forward-port the patches from
libffi_msvc.  I did attempt to use a vanilla libffi on Windows
sometime in 2014/2015, but ran into the issue that it doesn't have the
features ctypes wants, which made a few fairly basic tests fail.

Modules/_ctypes/libffi_arm_wince: I don't know why we even have this.
Nobody has touched it since ctypes was merged into cpython in 2006.

-- 
Zach
___
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] I am nos selectable in the bugtracker

[Zachary Ware]

On Fri, Dec 11, 2015 at 3:50 PM, Jesus Cea  wrote:
> After sending my new SSH key I have recovered "push" abilities in the
> mercurial repository, but it looks like I am not present in the bug
> tracker "assigned to" field.

I see you in 'assigned to', as 'jcea'.  Your own username is always at
the very top of the list.

-- 
Zach
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Python-buildbots] New installed Python builders

[Zachary Ware]

On Mon, Nov 23, 2015 at 3:11 PM, R. David Murray <rdmur...@bitdance.com> wrote:
> On Mon, 23 Nov 2015 19:11:15 +0200, Serhiy Storchaka <storch...@gmail.com> 
> wrote:
>> On 23.11.15 18:00, R. David Murray wrote:
>> > On Mon, 23 Nov 2015 00:58:01 -0600, Zachary Ware 
>> > <zachary.ware+py...@gmail.com> wrote:
>> > I haven't looked at this, but unless the buildbot does *not* have write
>> > access to the installed directories (ie: the install was done as another
>> > user) it isn't really doing a full installed python test.
>>
>> Yes, but at least it catches cases where some files are not installed.
>> There were few issues with this.
>
> True.  Something incomplete in this vein is better than nothing.  I'm
> Not sure you should call it "Installed" though, as that will be a bit
> misleading.  Most of the "can't run the tests on installed python" bugs
> are because the tree is read-only (obviously, not all of them!).
> Maybe call it "local install"?  Wordy, I know, but more accurate.

I've gone with attempting to make it more like a 'real' install, by
wrapping the test step with appropriate 'chmod' commands to make the
install directory not writable, and confirmed during a test run that
the entire installed tree is -w.  I also fixed the slave's usage of
usePTY (for test_curses) to avoid the failures that had been happening
in the 'uninstall' step.

-- 
Zach
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] New installed Python builders

[Zachary Ware]

Hi,

Inspired by a couple of issues about testing installed Python that
popped up this morning (#25694 and #25696), I've set up a new set of
builders[1] to build, install, and test the installed Python.  They
run on the same slave that runs my "x86 Gentoo Non-Debug with X"
builders.

If you are interested, please have a look at how they do what they do,
and let me know if you see any issues with how it's set up.  Since the
3.x builder is not failing, I'm not sure whether the issues have been
fixed or if I messed something up in the setup :)

[1] 
http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%203.x

http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%203.5

http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%203.4

http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%202.7

Regards,
-- 
Zach
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Reminder: 3.5 now has its own branch! default branch is now 3.6!

[Zachary Ware]

On Mon, May 25, 2015 at 3:10 PM, Larry Hastings la...@hastings.org wrote:

 On 05/25/2015 02:03 AM, Serhiy Storchaka wrote:

 Perhaps needed version bump in the default branch? I think now Misc/NEWS
 will have two modifiable sections - for 3.5 (bugfixes) and for 3.6 (new
 features).


 That's a good point!  I've added a 3.6.0 alpha 1 section as you suggest.

Should probably also actually bump the version (default still says
it's 3.5.0b1: Python 3.5.0b1+ (default:cf7e905ef5dd+, May 25 2015,
15:34:05)).

--
Zach
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposing Paul Moore for commit privileges

[Zachary Ware]

On Sat, Mar 14, 2015 at 3:23 PM, Brett Cannon bcan...@gmail.com wrote:
 Paul has been participating on python-dev for quite a while, he is a
 committer on pip, and (co-)author on 5 PEPs. At this point I think it would
 be prudent for Paul to have commit privileges if for any other reason than
 to help manage the code related to his PEPs. But on top of that I bet Steve
 wouldn't mind more help managing Windows-specific stuff.

+1, definitely.

--
Zach
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 3.4 buildbots??

[Zachary Ware]

On Mon, Mar 17, 2014 at 9:16 AM, Martin v. Löwis mar...@v.loewis.de wrote:
 Am 17.03.14 14:52, schrieb Jesus Cea:
 Do I need to do anything to create the 3.4 branch in the buildbots?.

 As a slave operator, you don't need to do anything. As the master
 operator, you would have to edit the configuration file to add the
 branch.

 However, I would advise against doing so now, and delay the addition
 of the 3.4 branch until 3.3 is retired from bug fixing, and then
 repurpose all 3.3 configuration for 3.4. Otherwise, some slaves might
 run out of disk space.

Since we still have a 3.2 configuration (for which most of the UNIX
bots are broken), perhaps we should repurpose that configuration
instead of 3.3.

 As the master operator, it would also be nice to slave operators if
 the 3.3 build directories get cleaned up, by targeting them to

 http://hg.python.org/buildbot/empty/

 once, and triggering a rebuild.

It would also be good to clear out the external library sources for
the Windows buildbots to allow a fresh start there.

--
Zach
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] RC phase?

[Zachary Ware]

On Thu, Feb 13, 2014 at 8:46 AM, Georg Brandl g.bra...@gmx.net wrote:
 Am 13.02.2014 14:15, schrieb Antoine Pitrou:

 Hello,

 So how is the RC phase supposed to work this time? Usually only critical
 patches get in, but I see a lot of commits in the last few days.

 For 3.3.0 bugfixing continued on default, and I cherry-picked patches I
 considered critical enough into my release repo.  The rest of the
 fixes were then merged after final and made their way into 3.3.1.

 Larry has a similar plan for 3.4, and I think he will announce it here 
 shortly.

That sounds like a good plan to me, and if that's going to be the plan
for the foreseeable future I think the devguide needs bit of an
update.  In particular, with this plan the absolute requirement of
having another core developer review a patch before commit can be
relaxed somewhat, since the RM would be reviewing any post-RC patches
in any case to decide if they should make Final.

Either way, some clarification would be good; I have a couple of
issues that I'd like to commit, but I'm wary of doing so until current
protocol is better defined.

--
Zach
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] Buildbot issues?

[Zachary Ware]

Hi all,

Just got this output from pushing a commit:


pushing to ssh://h...@hg.python.org/cpython
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote: buildbot: change(s) NOT sent, something went wrong:
remote: buildbot: [Failure instance: Traceback (failure with no frames): class
'twisted.internet.error.ConnectError': An error occurred while connecting: 113:
 No route to host.
remote: buildbot: ]
remote: sent email to roundup at rep...@bugs.python.org
remote: notified python-check...@python.org of incoming changeset c964b6b83720


Trying to load buildbot.python.org timed out as well.  Has the fleet
sailed away?

--
Zach
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PyCon Language Summit: Wednesday 9th April

[Zachary Ware]

On Wed, Dec 4, 2013 at 6:22 AM, Michael Foord mich...@voidspace.org.uk wrote:
 Hello all,

 As with previous years we will be having a Language Summit at PyCon North 
 America, in Montreal. The summit will be on Wednesday 9th April and running 
 from approximately 10am to 4pm.

 As Python committers you're invited, but please respond if you're attending 
 so I can track numbers.

How soon do you need to know?  I would really like to be there, but I
don't know when/if I'll be able to say that I will be.

--
Zach
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] Thank you

[Zachary Ware]

Hi all,

Just wanted to briefly say thank you for the vote of confidence in
accepting me into your ranks.  I'm looking forward to working with
such a great group of people on such a great project for a long time
to come!

Thanks,

Zach Ware
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers