Re: [python-committers] Codecov and PR

[Barry Warsaw]

On Apr 24, 2017, at 09:32 PM, Ethan Furman wrote:

>> I dislike code coverage because there is a temptation to write artficial
>> tests whereas the code is tested indirectly or the code is not important
>> enough to *require* tests.
>
>If it's not important enough to require tests it's not important enough to be
>in Python.  ;)

"Untested code is broken code" :)

-Barry
___
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] Github reviews are cannibalizing BPO

[Barry Warsaw]

On May 02, 2017, at 03:54 PM, Donald Stufft wrote:

>To touch on this a bit more, arguably GitHub is *more* suited to long form
>discussion, given that it includes the ability to format your text which is
>an incredibly important part of producing readable content more then a few
>sentences long. You can attempt to apply some of this with bpo using ASCII
>representations, but an inlined URL or a footnote to the URL is never going
>to be as good as a hyperlink, or an inlined image, or bold, italics, etc.

This might be true w.r.t. GH vs. bpo, but both of them are inferior IMHO to
mailing lists or other types of threaded discussions.  Personally, I find
GitLab to have a better conversational UX than GitHub, but neither is threaded
so it forces the discussions to be linear.  That's okay for many discussions,
but far inferior to more wide ranging discussions.

-Barry
___
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] Github reviews are cannibalizing BPO

[Barry Warsaw]

On May 05, 2017, at 10:58 AM, Steven D'Aprano wrote:

>On the other hand... I can imagine some developers thinking "I just 
>spent all this time porting my library to Python 3 for free, if I had 
>known I would have waited".

Except, think of the costs in mental anguish staying on Python 2. :)

-Barry
___
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

[Barry Warsaw]

On May 23, 2017, at 06:15 PM, Brett Cannon wrote:

>As usual, if you support/object to this idea, please say so. :)

Support!
-Barry
___
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] Revert changes which break too many buildbots

[Barry Warsaw]

On Jun 14, 2017, at 11:00 PM, Victor Stinner wrote:

>Since I'm trying to always keep the highest number of green buildbots,
>I prefer to try to fix the bug myself.
>
>My question is what to do if I'm unable to fix the issue and the
>author is not available. Keep a broken CI for hours, sometimes for
>days. Or revert the change to reduce the pressure and get more time to
>write a *proper* fix?
>
>I propose to revert to get more people at the issue to find the best
>option, rather than urging to push a quick & dirty fix.
>
>Hopefully, in most cases, the bug is trivial and I consider that the
>fix doesn't require a review, so I push it directly.

I agree with you that if it's easy to fix, JFDI.  If not, revert it to keep
the buildbots green and inform the author about the problem.  For now that can
be to update the issue or PR so the author gets a mention, but later it can be
an autonag email.

-Barry
___
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] Please edit the commit message when merge a PR

[Barry Warsaw]

On Jul 10, 2017, at 04:57 PM, Victor Stinner wrote:

>I would prefer to ask the author to squash and/or rebase his/her
>commits rather than having to edit the commit message myself. I prefer
>that the commit message is part of the review, and not only done by
>the one who clicks on the Merge button.
>
>It would prefer mistakes in the commit message.
>
>GitHub PR UI is not ideal to review commit messages :-/

GitLab is roughly the same, and I always edit commit messages when squash
merging.  While ideally the author could do this, I think sensible commit
messages are more important, so +1 for having the committer edit them at their
discretion.

-Barry
___
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] My (positive) feedback on the new CPython workflow

[Barry Warsaw]

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 all the people who made
> that happen, and especially Brett for leading it.

Not that I’m suggesting anything should change, but just FWIW, I find Gitlab to 
have a much better conversational review tool than Github.  I often find myself 
getting lost in GH reviews (on many projects), but GL just organizes the 
conversation really well IMHO.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] My (positive) feedback on the new CPython workflow

[Barry Warsaw]

On Jul 18, 2017, at 11:01 PM, Brett Cannon wrote:

>It's very obvious, Barry, that you're playing the long game of trying to
>line up GitLab as the next platform once we grow tired of GitHub and need
>to switch in a few years. I'm on to you. ;)

That, and bringing back the diamond operator for realz.

-B


pgp3zy47wZ9Yb.pgp
Description: OpenPGP digital signature
___
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] My (positive) feedback on the new CPython workflow

[Barry Warsaw]

Ah, how deservedly superficial my title is:

% python3 flufl.py
  File "flufl.py", line 3
1 <> 2
   ^
SyntaxError: invalid syntax
% cat flufl.py
from __future__ import barry_as_FLUFL

1 <> 2

-Barry

> On Jul 19, 2017, at 11:31, Victor Stinner  wrote:
> 
> 2017-07-19 17:23 GMT+02:00 Barry Warsaw :
>> That, and bringing back the diamond operator for realz.
> 
> For people who don't know the "diamond operator" like me ;-)
> 
> haypo@selma$ python3
> Python 3.5.3 (default, May 10 2017, 15:05:55)
>>>> from __future__ import barry_as_FLUFL
>>>> 1 != 2
> SyntaxError: invalid syntax
>>>> 1 <> 2
> True
> 
> Victor



signature.asc
Description: Message signed with OpenPGP
___
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] mention-bot is dead, long live the (misnamed) CODEOWNERS file!

[Barry Warsaw]

On Aug 1, 2017, at 17:09, Christian Heimes  wrote:

> Marietta, Brett, thanks for your work!

Indeed!

> 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
> format we had a relationship user -> files. The new CODEOWNERS format
> has files -> users mapping with last rules trumps all semantic. We have
> to be careful to not override parts of a previous rules. I believe teams
> reduce the burden.

Using teams would also reduce conflicts on changes to CODEOWNERS.  We’d need 
only specify the teams and then can use the GH u/i to manage team membership.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] UPDATE 1: Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California

[Barry Warsaw]

On Jul 12, 2017, at 12:00, Ezio Melotti  wrote:

> Both the SFO and SJC airports seem to be close to Menlo Park. Is there any 
> preference on the airport? Does the hotel provide any shuttle service?

Personally, I prefer SJC.  It works out great for me because there are 
reasonably timed direct flights from BWI to SJC, and SJC is a fairly easy 
airport to navigate.  It’s closer to Menlo Park too (though when I come to the 
area, I go to Sunnyvale).  I’m not sure about shuttle service.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Py_UNREACHABLE

[Barry Warsaw]

I landed bpo-31338 / PR #3374 which adds a Py_UNREACHABLE() macro to master, 
along with some additional documentation in the C API describing this and a few 
other common macros.  If you’re writing or reviewing C changes that include 
unreachable code paths, please use this macro for consistency, instead of other 
approaches like assert() (which can be compiled out) and `return NULL`, etc.

As part of the PR, I changed a bunch of existing instances in the code:

https://github.com/python/cpython/pull/3374/files

If you find any cases I’ve missed, feel free to submit a PR and I will happily 
review it.  I think this makes our code more consistent and ultimately safer.

(Thanks Victor for the PR review!)

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Py_UNREACHABLE

[Barry Warsaw]

On Sep 15, 2017, at 12:36, Victor Stinner  wrote:
> 
> The good news is that other C macros are now documented as well!
> 
> https://docs.python.org/dev/c-api/intro.html#useful-macros
> 
> If you look at Include/pymacro.h there are even more crazy macros
> which are not documented yet, like Py_BUILD_ASSERT().
> 
> I like Py_ARRAY_LENGTH() which gives the length of an array and not
> its size in bytes. The macro is nice because it fails with a
> compilation error if the argument is not an array! For example, it
> fails on "char *not_an_array" or "char not_an_array_neither[];".

PRs anyone? :)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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: macOS is now blocking -- remove macOS from Travis CI?

[Barry Warsaw]

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 stable.
> 
> Are you ok to not add again the macOS job to Travis CI?
> 
> Again, my rationale is that we already have 3 macOS buildbots and I'm
> looking closely at all buildbot failures. I try to keep track of *all*
> failures, even random failure. A recent macOS example:
> https://bugs.python.org/issue31510
> 
> Sadly, remaining random failures are the most rare and most difficult
> to reproduce. (I fixed a lot of them last months.)

If the macOS tests aren’t stable, then yes, removing them is better than 
frustrating developers who can’t reproduce CI failures, even on the CI machines 
let alone their own development boxes.

I forget though, was it a problem with macOS CI stability or general 
throughput?  I thought they just couldn’t keep up with the workload, in which 
case it seems like we should be able to throw more resources at it, right?

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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: macOS is now blocking -- remove macOS from Travis CI?

[Barry Warsaw]

On Sep 19, 2017, at 19:33, Alex Gaynor  wrote:
> 
> If you find a macOS CI platform with more capacity, please let me know :-)
> 
> Travis has been totally underwater of late, but I don't know of any 
> alternatives; probably because operating a fleet of macOS builders is a giant 
> pain. You need Apple hardware, and it turns out you can either purchase a 
> trashcan or a mac mini, and neither of those is really designed for a server 
> farm.
> 
> If anyone here can magically whisper in Tim Cook's ear, can you ask him to 
> license macOS to AWS or Google Cloud or something?

Brett will love my musings: one could imagine a fleet of hackintoshes talking 
to a flexible CI runner infrastructure as is available on some alternative 
hosting platforms.  Not that I, ahem, know anything about that.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Should I merge a PR that I approved if it was written by a different core developer?

[Barry Warsaw]

On Sep 20, 2017, at 20:54, Nick Coghlan  wrote:
> 
> On 21 September 2017 at 07:27, Victor Stinner  
> wrote:
>> Hi,
>> 
>> Before the GitHub era, in the old "Mercurial era", the unwritten rule
>> was to not merge a patch written by a developer who has the commit
>> bit, to not "steal" his/her work. The old workflow (patches attached
>> to the bug tracker) didn't allow to easily keep the author. You had to
>> find the author email and full name and specify it manually.
> 
> I'll typically still just leave an "Approve" review rather than
> merging directly, unless it's a PR 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.

In general, I like the unwritten rule.  There’s something very satisfying about 
finally hitting the merge button, and as Nick points out, you may want to do 
some final tweaks.  I’ll usually just leave the Approve review too, and let the 
submitter/committer do the final merge.

That said, there are times when it’s useful to do the merge for them.  If it 
was my PR, I might leave a note in the PR asking for a merge if I know I won’t 
get to it soon (maybe I’m going on vacation), or if as Nick says, it needs to 
get merged soon so as to avoid conflicts or blocking other people’s progress.  
I’d still like it to mostly come from the original submitter.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] python-devs/python project on GitLab

[Barry Warsaw]

Back when we were deciding between GitHub and GitLab, we created this project:

https://gitlab.com/python-devs/python

Unless anyone objects, we’re going to delete this project.  We have no need for 
this now that CPython development is on GitHub.

(No, we’re not getting rid of the group, just the project.)

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Statistics: growth of core dev number vs growth of the code size/complexity

[Barry Warsaw]

On Dec 6, 2017, at 18:17, Victor Stinner  wrote:

> 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: 9
> 2013: 4
> 2014: 10
> 2015: 2
> 2016: 5
> 2017: 2

Thanks for the analysis.  Let’s do everything we can to get some of these newer 
core devs to the Language Summit in 2018!

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Official python-dev docker images

[Barry Warsaw]

As part of the importlib_resources skunkworks project Brett and I have been 
working on (just announced), we’ve also put together a nice Docker image that 
we’re using for our automated testing.  This image is based on Ubuntu 16.04 and 
provides the latest stable releases of Python 2.7, and 3.4-3.6, along with a 
mostly up-to-date git checkout of master, currently Python 3.7 of course.  Once 
3.7 is released to beta, we intend to track its release tarballs too.

We also install a few other commonly needed tools, like pip, git, unzip, wget, 
mypy, and tox.

Here’s the project repo:

https://gitlab.com/python-devs/ci-images

Huge shout out to Abhilash Raj who helped us clean up and compactify the image, 
and also for setting up automated publishing to quay.io.  In case you weren’t 
aware, Abhilash is who I passed GNU Mailman project leadership to, so he has a 
lot of Python experience, and a ton of expertise in the image space.  He’s an 
amazing amount of work to improve the quality of this image!

Brett and I want to promote this more widely within the Python community as the 
“official Python Docker image” that projects can use in their own testing 
environments, or base their own images on it.  We wanted to give you guys a 
heads up first to get your feedback, and maybe thoughts on the best places to 
promote this, e.g. on the python.org website or other places.

We welcome your participation too of course!  I’m happy to give write access to 
the project to any Python committer who wants to help.

Cheers,
-Barry, Brett, Abhilash



signature.asc
Description: Message signed with OpenPGP
___
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] Official python-dev docker images

[Barry Warsaw]

On Dec 7, 2017, at 13:00, Barry Warsaw  wrote:

> He’s an amazing amount of work to improve the quality of this image!

Um, let me rephrase :)

He’s done an amazing amount of work to improve the quality of this image!

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Official python-dev docker images

[Barry Warsaw]

[Continuing to CC Abhilash, who is not on this list. -B]
> On Dec 7, 2017, at 14:36, R. David Murray  wrote:
> 
> On Thu, 07 Dec 2017 13:00:31 -0500, Barry Warsaw  wrote:
>> Brett and I want to promote this more widely within the Python
>> community as the “official Python Docker image” that projects can use
>> in their own testing environments, or base their own images on it.  We
>> wanted to give you guys a heads up first to get your feedback, and
>> maybe thoughts on the best places to promote this, e.g. on the
>> python.org website or other places.
> 
> Well, the place to get a python Docker image listed would be
> https://hub.docker.com/_/python/.  That's the first google hit for python
> docker, and it already has a host of images available.  How does yours
> differ from those?  It sounds like it is by having multiple versions
> and tox so you can test your library/ap against multiple Python
> versions using a single container.  That does sound useful :)

There are several differences.  Probably the two biggest are that 1) the ones 
on docker hub are not maintained by *us* but instead by “the Docker Community”; 
2) AFAICT, the ones on docker hub aren’t development focused images, so they 
only have one single version of Python installed.  For any Python-based project 
that wants to e.g. run CI against multiple versions of Python, that isn’t 
helpful (and hence why we built this one).  Our image is bigger, but more 
generally useful to library and application developers, rather than say, 
application deployment users.

> But, be careful with names.  "official Python Docker image" sounds like
> what one would use when one wants to *run* a python application in a docker
> container, which is what the images that are currently listed on the
> page mentioned above seem directed at.

That’s good feedback!  I want to be clear about the purpose of this image, both 
in that it’s blessed and maintained by us, and that its focus is on the Python 
library and application developer (primarily for testing purposes).

So maybe: Python.Org Official Multiversion Development Docker Image Doubleplus 
Good!

:)

Seriously, audience and naming are important to get right.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Official python-dev docker images

[Barry Warsaw]

On Dec 7, 2017, at 19:34, Christian Heimes  wrote:
> 
> Shiny! You'll get extra bonus points for not running as root. :)

Don’t forget, there’s a bug tracker you can submit requests to. 

> I'm curious, what is the reason of compiling CPython yourself? Ubuntu
> has the deadsnakes project. Fedora has packages for Python 3.3, 3.4, and
> 3.5.

I really want clean builds of upstream tarball releases.  Debian/Ubuntu for 
sure, and I would bet Fedora too, has downstream deltas applied, so if 
something fails there, how do you know it’s because of your package or 
something the distro added?  Note that we do install the build dependencies for 
the Pythons so they’ll link against platform libraries and such.

> Could I convince you to put some builds of OpenSSL and LibreSSL into the
> container, too?

You can totally file an issue so we can discuss it. :)

https://gitlab.com/python-devs/ci-images/issues

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug)

[Barry Warsaw]

On Dec 9, 2017, at 20:41, Nick Coghlan  wrote:
> 
> +1 - "Who am I to have this power?" is a pretty common reaction to
> community promotions, so erring on the side of "I trust your
> judgement, so you should trust your judgement" is a good way to go.
> 
> But at the same time, we should make it clear that "Help me better
> calibrate my judgement" is an entirely appropriate use case for the
> core-mentorship list (and we keep those archives closed so they're not
> available to search engines).

Very well said, Nick.  It’s useful to remind new contributors that very few 
things are irreversible, and that there are lots of outlets for asking 
questions.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Official python-dev docker images

[Barry Warsaw]

On Dec 7, 2017, at 19:00, Christian Heimes  wrote:
> 
> Why is there 'Docker' in the name? Is the container image restricted to
> Docker runtime or can I use it with lxc, systemd-nspawn, rkt, or any
> other container runtime, too?

I honestly don’t know, and I’ve only used it with Docker, but there is the Open 
Container Initiative to promote standards, so maybe it can.

https://www.opencontainers.org/about

> There are likely legal issues with the name, too. After all 'Docker' is
> a registered trademark of Docker, Inc [1]. I'd be careful and call it
> 'Python.Org Official Multiversion Development Supercalifragilistic
> Container Image' instead.

Yeah, that’s a good suggestion.  Well, maybe without the Potential Poppins 
Infringement.

(And yes, I’m going to follow up on python-dev now.)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Date of the Python Language Summit?

[Barry Warsaw]

On Dec 19, 2017, at 09:35, Victor Stinner  wrote:
> 
> I'm starting to organize my travel to Cleveland for Pycon US 2018. I
> would like to know when will be the Python Language Summit to be able
> to decide how many nights I will stay. The hotel is usually a huge
> part of the budget.

Traditionally, we’ve held the summit on the first day of tutorials.  Larry and 
I haven’t started planning 2018’s, but I expect the tradition to hold.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Security: please enable 2-factor authentication on GitHub and your email

[Barry Warsaw]

On Jan 6, 2018, at 14:00, Alex Gaynor  wrote:
> 
> Hey Antoine,
> 
> Assuming you're on Firefox57, it requires a pref -- once the WebAuthn spec is 
> finalized we'll drop the pref -- 
> https://mobile.twitter.com/jamespugjones/status/91231495223226

Oh wow, this is exciting!  I’ve been annoyed by the lack of support for my 
Yubikey in FF57, but I just enabled these and quick check by logging into GH 
seems to show that it works, at least for some sites.  Thanks for the link.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Let's give commit privileges to Nathaniel J. Smith

[Barry Warsaw]

On Jan 24, 2018, at 18:23, Yury Selivanov  wrote:
> 
> I want to propose granting commit privileges to Nathaniel J. Smith.

Wait, he’s not already?!  +1 of course.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Welcome the 3.8 and 3.9 Release Manager - Łukasz Langa!

[Barry Warsaw]

As Ned just announced, Python 3.7 is very soon to enter beta 1 and thus feature 
freeze.  I think we can all give Ned a huge round of applause for his amazing 
work as Release Manager for Python 3.6 and 3.7.  Let’s also give him all the 
support he needs to make 3.7 the best version yet.

As is tradition, Python release managers serve for two consecutive releases, 
and so with the 3.7 release branch about to be made, it’s time to announce our 
release manager for Python 3.8 and 3.9.

By unanimous and enthusiastic consent from the Python Secret Underground (PSU, 
which emphatically does not exist), the Python Cabal of Former and Current 
Release Managers, Cardinal Ximénez, and of course the BDFL, please welcome your 
next release manager…

Łukasz Langa!

And also, happy 24th anniversary to Guido’s Python 1.0.0 announcement[1].  It’s 
been a fun and incredible ride, and I firmly believe that Python’s best days 
are ahead of us.

Enjoy,
-Barry

[1] 
https://groups.google.com/forum/?hl=en#!original/comp.lang.misc/_QUzdEGFwCo/KIFdu0-Dv7sJ



signature.asc
Description: Message signed with OpenPGP
___
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] Welcome the 3.8 and 3.9 Release Manager - Łukasz Langa!

[Barry Warsaw]

On Jan 27, 2018, at 17:04, Guido van Rossum mailto:gu...@python.org>> wrote:
> 
> Hardly a surprising choice! Congrats, Łukasz. (And never forget that at every 
> Mac OS X upgrade I have to install the extended keyboard just so I can type 
> that darn Ł. :-)

Heh, I *just* learned that, at least on macOS High Sierra (and probably going 
back several releases), on a US keyboard you can press and hold the ‘L’ (cap-L) 
key.  A little popup will appear like the attached image (if this doesn’t get 
stripped by Mailman).  Hit ‘1’ and the slashy-L will get entered: Ł.

Cheers
-Barry


signature.asc
Description: Message signed with OpenPGP
___
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 created the "needs backport to 3.7" label on GitHub

[Barry Warsaw]

On Jan 31, 2018, at 18:58, Mariatta Wijaya  wrote:
> 
> I'm not sure. Maybe the release managers know? There is PEP 101..

I’ll bet Ned is either updating PEP 101 as he goes, or is keeping notes to 
update that PEP once things calm down.  It’s a rare enough event, and this is 
the first time with git, so I’m sure there was a fair bit to figure out.

$ git worktree add ../3.7 3.7  # ftw!

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] cherry picking, miss islington, and generated files

[Barry Warsaw]

I’m in the process of back porting a change which touches importlib and 
requires regeneration of Python/importlib.h and Python/importlib_external.h.

The original fix on master:
https://github.com/python/cpython/pull/5481

Miss Islington’s back port to 3.7:
https://github.com/python/cpython/pull/5498

Miss Islington was not able to auto-pick this into 3.6, which makes sense.

I got a little concerned though that the back port touches those two generated 
files, and didn’t feel comfortable just pushing the Big Green Button.  I 
chatted with Brett and he also agreed that the merge should probably be done 
manually.  So for the 3.7 merge, I actually followed the GitHub CLI merge 
instructions, regenerated the .h files, pushed the branch, and opened a new PR:

https://github.com/python/cpython/pull/5503/files

Once CI passed, I hit the BGB and the merge occurred as normal.

For the 3.6 fix, I used cherry_pick, resolved the conflicts manually, regen’d 
the header files, pushed the branch, and submitted a new PR:

https://github.com/python/cpython/pull/5504

This one’s still running CI, but if it passes, I’ll merge it.

I wanted to mention this because maybe Miss Islington should flag, warn, or 
otherwise indicate when autogenerated files are being merged?  Are there any 
other files other than the importlib .h files that we should take extra care 
with?

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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

[Barry Warsaw]

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.

> I need to dig up that thread and find out if anyone answered. It's been a 
> while :)

Cool, thanks!  I definitely missed the discussion the first time around.

> Usually there would be conflict in backport though. It was suggested that 
> cherry-picker can regenerate the files and resolve the conflict.
> Your suggestion of having miss Islington comment on the PR sounds good too.

In my case, there was no conflict, although I actually thought there might have 
been one.  But I was still uncomfortable not manually regenerating those files 
anyway.  The 3.6 auto-merge did have conflicts because the commit touched a 
file that doesn’t exist in 3.6, but cherry_picker worked beautifully so it 
wasn’t difficult to resolve.

I don’t think this is a common situation, since importlib is a bit more of an 
esoteric part of the stdlib, and cherry picking fixes in it is probably even 
more rare.  At least it’s something to be aware of, and anybody who changes 
importlib will already know they have to do something special (i.e. regenerate 
the files).

Thanks for your great work on these tools Mariatta!

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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

[Barry Warsaw]

On Feb 3, 2018, at 23:16, Mariatta Wijaya  wrote:
> 
> I found the related thread in core mentorship mailing list:
> https://mail.python.org/mm3/archives/list/core-mentors...@python.org/thread/CNK7EWWZTDIRID7MTWLTWXU4H7IH3UIE/

FYI, core-mentorship’s archives can’t be read without a subscription.

> Guido and Victor answered, I guess I got distracted with other things and 
> forgot to do any sort of follow up :P
> 
> If I understand it right, they both suggested running "make regen-all" at 
> each backport.
> But you seem to indicate that you rather do that manually?

Not necessarily.  I think the only option right now is to run it manually, but 
if the bot can do that automatically (and probably add a comment that it’s done 
so), that would be great.

> For the first pass, I think it can detect that when a changeset includes 
> importlib.h, we'll make miss-islington leave a comment about needing to 
> regenerate files.

+1

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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

[Barry Warsaw]

On Feb 5, 2018, at 09:09, Nick Coghlan  wrote:
> 
> Heh, I think I have a plausible theory as to what happened:
> 
> The 3.7 and 3.8 compilers are currently still identical, and this was
> the first post-branch change to importlib (as far as I know), so:
> 
> 1. The patch applied cleanly (because the previously frozen versions
> were the same)
> 2. The regen check passed (because the regenerated version was the same)

Agreed.  I just wasn’t *positive* I could trust a clean merge and passing 
tests.  Maybe we can though.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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

[Barry Warsaw]

On Feb 6, 2018, at 15:30, Mariatta Wijaya  wrote:

> So, maybe we trust the CI a little bit more now when it comes to checking if 
> regenerated files are needed :)

Great, thanks for checking Mariatta!  It definitely gives me more confidence 
that if the bot and CI pass, the merge will be good.  If it comes up again, 
I’ll run that experiment for real. :)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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 Petr Viktorin as a specialist core developer

[Barry Warsaw]

On Apr 13, 2018, at 05:13, Nick Coghlan  wrote:
> 
> I'd like to propose Petr Viktorin as a specialist core developer,
> focusing on extension module imports.

+1

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Comments on moving issues to GitHub

[Barry Warsaw]

On May 20, 2018, at 10:19, Nathaniel Smith  wrote:
> 
> IIRC, the general reaction was that it was definitely worth exploring, but 
> that it would be a lot of work and require solutions to a lot of problems to 
> make sure people's workflows weren't too impacted, so we'd need a much more 
> detailed proposal before any decision could be made.

Note too that Bryan Clark from GitHub, who I believe is a product manager 
there, was at the packaging mini-summit.  If/when we have a specific set of 
asks for the migration, we can reach out to him and see how they can help.  For 
example, I specifically asked about my favorite GitLab feature “commit when CI 
passes” and it sounded like they were working on that.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Comments on moving issues to GitHub

[Barry Warsaw]

On May 21, 2018, at 03:24, Nick Coghlan  wrote:

> Right, one of the outcomes of the discussion at the Summit was that any 
> proposal to migrate to a different issue tracker would need to present a 
> clear statement of the *problems intended to be solved*, such that the folks 
> that would prefer to see us stay on our own issue tracker could present a 
> competing proposal to solve those problems without a wholesale migration to 
> another system.

I’d like to see multiple PEPs for this migration.  The first would clearly 
outline discussion points that apply regardless of where we migrate to, or 
whether we migrate at all.  This would include lists of common use cases, the 
problems with the current system, the features we like (and regularly use!) in 
the current system, and a list of key points that can be compared against any 
proposed solution.

E.g. for this latter, let’s say one of the points is “ability to easily ignore 
all discussions on tickets you don’t care about”.  You could imagine a row in a 
table that shows how any of the proposed solutions compare to what we have 
today.  You could color code this on a gradient, say from dark green (“it will 
be much better on system X”) to dark red (“it’ll be much more difficult on 
system Y”).

That would be one PEP, and it would be the baseline for making a decision.  
Additional PEPs would make specific proposals, e.g. move to GH, stay on bpo as 
is, significantly invest in bpo, etc.  They’d reference the baseline PEP and 
include that table with the color coded rows.

Then perhaps after the decision is made, there would maybe be an implementation 
PEP describing the steps it will take to migrate, and the ETA.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] A different way to focus discussions

[Barry Warsaw]

[I think my other response got dropped, so apologies for any duplicates]

Guido van Rossum wrote:
> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.

I don't think I'd want to see tons of new PEP repos under the current `python` 
organization.  Maybe we should create a new organization for this experiment?

Also, since non-core devs can and do create PEPs, the permission management 
will be different than the normal repos.  Clearly the PEP authors should be 
owners of the individual repos, but they should probably also decide how merges 
happen, and who else can contribute to their repo.

It also means that PEP editors probably have an additional responsibility to 
create the PEP repo.

PEP 1's Discussions-To header can probably be co-opted for the URL to the GH 
repo.  Right now, that field is described as an email address, but it would be 
appropriate IMHO to also allow a URL for discussions.

> Thoughts? (We can dogfood this proposal too, if there's interest. :-)

I don't know whether this will help focus rambling PEP discussions.  I 
personally don't love the linearity of GH comments.  Threading is useful!

OTOH, it seems like a low-cost experiment to try so if there's a volunteer who 
wants to be the guinea pig, I'm fine with it.

-Barry


signature.asc
Description: Message signed with OpenPGP
___
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] A different way to focus discussions

[Barry Warsaw]

On May 22, 2018, at 12:44, Guido van Rossum  wrote:
> 
> Hm, what's the cost of those extra repos? As long as they have consistent 
> names (e.g. pep-1234) they're easy to ignore right? Or does GitHub have a 
> quota of repos per org?

I think there is a quota for non-paying organizations, but I’m not sure.  I was 
just thinking about clutter on https://github.com/python but maybe it won’t be 
so bad with…

> I was thinking of a workflow where the pep author initially creates the repo 
> under their own username and directs discussion there. Then when their PEP is 
> accepted (or rejected!) they can donate their repo to the python org. I know 
> such a thing is possible (we did it for the mypy and typeshed repos).

… +1!

> Ironically for me GitHub is less linear than email. It's easier to ask people 
> to open a new issue than it is to ask them to start a new thread. So e.g. if 
> a discussion starts about a survey of feature X in various languages, when it 
> veers off into a tutorial for a specific language that could be a separate 
> issue, and the meta-discussion on how the list of languages should be 
> selected could be made another issue.

I see what you’re saying.  Yes, that could work if the PEP author is really 
diligent about shunting detours into new issues.  I’ve just found that within 
PRs or issues, the linearity can be quite difficult to follow.  (FWIW, IMHO, 
GitLab does better here, but that’s besides the point.)

> I think Mark Shannon volunteered PEP 576 (though so far he hasn't created a 
> separate repo, he's just created a PR for the peps repo IIUC). I hope Nick 
> will also volunteer PEP 577 for this.

+1

-Barry


signature.asc
Description: Message signed with OpenPGP
___
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] Comments on moving issues to GitHub

[Barry Warsaw]

On Jun 1, 2018, at 16:54, Antoine Pitrou  wrote:
> 
> I wonder if other hosted services, such as Gitlab, offer a more
> sophisticated issue tracker.

Not really.  Mailman has a little less than 200 open issues, but they are 
basically categorized in the same way as GitHub, i.e. via labels.

https://gitlab.com/mailman/mailman/issues

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Transfer of power

[Barry Warsaw]

On Jul 12, 2018, at 07:57, Guido van Rossum  wrote:
> 
> I would like to remove myself entirely from the decision process. I'll still 
> be there for a while as an ordinary core dev, and I'll still be available to 
> mentor people -- possibly more available. But I'm basically giving myself a 
> permanent vacation from being BDFL, and you all will be on your own.

Leaving my emotions out of it for now, and with my heartfelt gratitude for 
everything you’ve done, I am absolutely certain that the community you’ve built 
is strong enough to carry on.

I’m honored that a some of you think I can fill 1/3 of Guido’s shoes, although 
in all humility I have my doubts.  Aside from that, it’s important to recognize 
that we have so many intelligent and compassionate contributors, that much of 
Python’s ongoing development can essentially carry on unchanged.  Yury, for 
example worried about replacing Guido’s extensive knowledge across so much of 
Python, and there’s the concern that Guido’s unique authority as BDFL will be 
difficult to replicate.  E.g even if you still absolutely hate PEP 572 (which I 
don’t), it is now unequivocally part of Python.  It’s up to all of us to accept 
that, move on, and learn to use it tastefully.

I think this change in governance will increase the importance of the 
BDFL-Delegate.  We have trusted experts in many of the sub-topics of Python, 
and I have so much more confidence in letting them make the decisions relevant 
to those sub-topics.  E.g. Nick, and now Paul for packaging, Yury et al for 
async, etc.  I know that experts and BDFL-Delegates will make the right choices 
in these sub-topics, with the right intentions, and the best of their 
abilities.  Even Guido recognizes that we’re all just trying to do our best.

Where the BDFL role is most important is in those holistic decisions about 
global features, such as PEP 572.  These things impact everyone and every 
corner of Python, so having a final arbiter(s) that is accepted by the 
community at large is critical.  I’ve long said that if I had to choose a 
single person to fill that role, it would be Brett.  He has the right mix of 
technical and social chops to make thoughtful, intelligent, compassionate 
decisions, and he has the advantage of being likely more than a decade away 
from Guido in hopeful retirement plans, unlike perhaps that FLUFL guy. :)

That said, I think a triumvirate would work (Guido’s Unworthy Inherited 
Delegation Organization).  Mostly, that group would identify and work with 
Delegates to make the final decisions on such PEPs, and most importantly, 
confidently back them up, even if those decisions are unpopular.

For PEP 572-level language decisions, the group would be the final arbiters, so 
it would have to be an odd number.  I agree with Brett that voting and rotation 
could be problematic due to the tyranny of the majority.  Imagine that PEP 572 
were put in front of this group, and after all the kerfuffle, the same decision 
were made.  Put yourself in that place when you think about the governance of 
Python-the-language over the next 25 years.  I personally value stability and 
certainty over popularity for such features.  PEP 572 won’t destroy Python, and 
I predict most of us will appreciate it being there once in a while.

There’s no rush to decide, and this would make for a fine discussion at the 
core sprint in September.

Cheers,
-Barry





signature.asc
Description: Message signed with OpenPGP
___
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] Transfer of power

[Barry Warsaw]

On Jul 12, 2018, at 11:16, Steven D'Aprano  wrote:
> 
> https://www.python.org/dev/peps/pep-0401/

And of course, Uncle Timmy was the original FLUFL, before Guido and Brett did 
their nefarious edits. :)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Transfer of power

[Barry Warsaw]

On Jul 12, 2018, at 11:21, Tim Peters  wrote:
> 
> If Barry had been BDFL all along, only features useful to Mailman would have 
> gotten in ;-)

I would have stuck around just long enough to kill off !=

diamonds-are-a-flufl’s-best-friend-ly y’rs,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Transfer of power

[Barry Warsaw]

On Jul 12, 2018, at 12:16, Brett Cannon  wrote:
> 
> Maybe another way to label this is design stewards? We seem to be suggesting 
> a cabal of folks who steward the overall design while relying on experts as 
> appropriate to handle finer details.

I like that distinction.

-Barry




signature.asc
Description: Message signed with OpenPGP
___
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] Transfer of power

[Barry Warsaw]

On Jul 13, 2018, at 15:11, Jack Jansen  wrote:
> 
> How about a triumvirate (or trium*ate if “vir” is seen as too male-centric, 
> and actually the “3” isn’t important either) where unanimity is required for 
> language changes (i.e. basically for accepting a PEP)?

Possibly, but even if unanimity can’t be achieved, I feel strongly that any 
decision coming from the GUIDO/Cabal/Council should be give as a single party.  
E.g. if Alice and Bob +1 PEP 801 and Carol -1’s it, I don’t think any purpose 
is served by breaking that out into individual votes.  I would hope that the 
council members support each other and the body’s decision even if it doesn’t 
go an individual’s way.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Transfer of power

[Barry Warsaw]

On Jul 13, 2018, at 02:30, Anthony Baxter  wrote:
> 
> As someone who's not been involved for some time now, but was release manager 
> for a three or four years (2.3.1 through to 2.5.1), trying to have the 
> release manager also be a decider of potentially controversial things doesn't 
> seem scalable.
> 
> I'm not sure what the proper governance structures should be, but they 
> absolutely shouldn't be dumping extra load onto the release manager.

My thinking is that the current RM can serve a useful role on the Council, but 
not in a voting capacity.  Some possible scenarios:

* A Council member wants to author a PEP.  They probably shouldn’t also get to 
vote on the PEP’s acceptance, so the RM can serve as a replacement vote for 
that one PEP.  (Maybe only for Standard Track PEPs).

* If a Council member is temporarily unavailable, the RM can serve in their 
place during that period.

* The RM can give valuable insight that may influence Council members votes.  
Maybe the PEP’s implementation is too difficult for the current release, and 
recommends deferral.

* If the Council also decides on the “PEP-worthiness” of an idea, the RM can 
weigh in based on their unique perspective on the release cycle.

* The RM can provide an independent oversight role on the Council, kind of like 
an ombudsman (or maybe that should be a separate role, although I suspect it 
will be rarely invoked in practice).

I would propose that the RM be involved with Council communications, but does 
not get a vote.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Identify roles of the BDFL

[Barry Warsaw]

On Jul 13, 2018, at 03:40, Victor Stinner  wrote:

> Should we split the role "take the final decision on PEPs" into
> sub-roles for example? Do we need in advance to define BDFL-delegate
> for some kinds of PEPs? Or the BDFL should define per-PEP, which ones
> he doesn't want to handle and need a BDFL-delegate? In my experience,
> the BDFL delegation was done naturally, was not the source of
> conflict, and usually discussed directly with the BDFL.

I don’t think we need to be so formal about delegation.  As you say, it should 
generally happen naturally.

I actually think delegation will be more common, leaving mostly the 
language-level Standards Track PEPs for the BDFL (Benevolent Design Faction 
Lifers - okay, still playing with names :).

One tricky thing with delegation will be when a natural delegate is also the 
author of the PEP. For example, if Yury proposed some changes to async, he 
wouldn’t also be able to pronounce on it.  OTOH, Guido is of course still a 
developer and could be a delegate for such PEPs if he wants.  Just something to 
be aware of.

It’s possible that more decisions that have previously been informal will be 
best served by the PEP process.  For example, the pronouncement that 
dictionaries officially preserve insertion order would likely be handled as a 
succinct PEP.  One of the roles of the council would be to decide whether a 
change is PEP-worthy or not.  It’s possible that ideas that only show up on the 
tracker for example, need to be promoted into a PEP, and it would be up to the 
developer community to help identify those potential changes.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Organizing an informational PEP on project governance options (was Re: Transfer of power)

[Barry Warsaw]

On Jul 13, 2018, at 04:31, Nathaniel Smith  wrote:
> 
> I volunteer to co-author such a PEP. But I'm not up to doing it on my
> own. So... who else wants to be a co-author? (I'm not going to
> pressure anyone, but Brett, Mariatta, and Carol, please know that your
> names were the first ones that jumped to my mind when thinking about
> this :-).)

Count me in.

Procedurally, I think an informational PEP numbered in sequence is a good place 
for the “design” of our governance.  Once we’ve settled on a plan, we would 
capture the operational procedures in a new process PEP (I propose PEP 2), 
which would be our working document moving forward.  I think it’s pretty much a 
certainty that whatever we come up with initially will undergo changes as time 
goes on and we gain experience.  PEP 2 would then be the living document for 
our language governance process.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Identify roles of the BDFL

[Barry Warsaw]

On Jul 13, 2018, at 17:11, Carol Willing  wrote:

> If I look at the many important roles that Guido has played, I personally 
> believe that he has been someone who encouraged many women (and I'm sure 
> others as well) and most importantly provided a safe place to share ideas. If 
> we reflect on Mariatta's PyCon talk and Summit talk, it's clear that we 
> should not overlook this role as growth and improvements still need to happen 
> here.

Maybe we refactor this particular role of the BDFL?  It may be that given 
Guido’s passion for this topic, he would still want to be active.  If so, he 
would certainly still have the stature, respect, and voice to continue to 
promote this within the community.  Of course, we don’t know whether that’ll be 
the case or not.

It’s a good question though: should the Council primarily concern itself with 
technical details of language evolution, or take on more of the other roles 
that Guido traditional performed?  Or do you see more of an overlap there 
(other than through the person embodying that role)?

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Transfer of power

[Barry Warsaw]

On Jul 14, 2018, at 00:16, Łukasz Langa  wrote:

> Taking a step back, before we talk names, term limits and even numbers of 
> council members, Python needs a "constitution" which will codify what the 
> council is and how it functions. Barry calls it PEP 2 but I'd like to 
> understand who is supposed to author it and who is supposed to accept it.

Yes, I’ve been thinking the same thing.  PEP 2 would serve as the Python 
development constitution.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] An alternative governance model

[Barry Warsaw]

I’d like to propose an alternative model, and with it a succession plan, that 
IMHO hasn’t gotten enough discussion.  It’s fairly radical in that it proposes 
to not actually change that much!

TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors that 
helps the BDFL in various capacities, with additional responsibilities.  I also 
have someone specific in mind for the NBDFL, but you’ll have to read on for the 
big reveal.

Why keep a singular BDFL?  I think it’s clear that no one can completely 
replace Guido, and neither should we try, nor do we need to.  The discussion to 
date has explored refactoring many of the roles that the BDFL has, and that’s 
all excellent, especially to reduce the burden and burnout factor of the NBDFL. 
 But I think having a singular BDFL making the tough decisions, with the 
support and help of the community, is in the best interests of Python over the 
long term.

A singular BDFL provides clear leadership.  With a council of elders, it will 
be more difficult to communicate both to the Python community, and to the 
larger, more peripheral user base, that any particular individual has the 
authority to make decisions.  Regardless of size, there would ultimately be 
some one person communicating any council decision.  There will inevitably be 
ambiguity as to the authority of said decision.  How will folks, especially on 
the periphery, know that Alice Jones or Bob Smith are members of the council 
and can speak authoritatively on decisions for the language?  “Bob Smith, on 
Behalf of the GUIDO” is IMHO less obviously and unquestionably authoritative 
than “Alice Jones, BDFL”.

This also comes into play for shutting down discussions early.  With a 
committee, it’s possible that you’ll have some disagreement among the members 
as to whether a discussion is fruitful or not, whether it rehashes settled 
questions, or whether the change fits into the overall direction for Python’s 
evolution.  Alice Jones may say “No, that’s not gonna happen” only to be 
overruled or undermined by Bob Smith’s “That’s a good idea”.

Taken together, these fall under the umbrella of having one voice for the 
decision making process.  It may be possible for consensus within the council 
to come across as a single voice, but I think it will generally be harder.  A 
council also opens the door for more back-channel lobbying of a sympathetic 
member.  Yes, such lobbying is possible with a BDFL, but at least there should 
be less contention.

I also think a council will be much more risk adverse than a singular BDFL, and 
that’s not necessarily a good thing.  While moratoriums and a more conservative 
approach to change may be appropriate at times, I would prefer those to be 
deliberate decisions for a specific purpose, rather than the unintended outcome 
of groupthink or lack of consensus.  A singular BDFL with support from the 
community will have more authority to make decisions which probably will never 
be universally accepted, and much less prone to vapor lock due to lack of 
consensus or internal bickering.

I hope Guido won’t mind me relating a comment of his that has really resonated 
with me over the last few days, and for which I think a singular BDFL will be 
much more adept at communicating and shepherding.  The question for any new 
leader is:

What is your vision for Python?

This question keeps coming to mind as I think about how the evolution of the 
language will be governed over the next few years or decades.  Yes, Python is a 
mature language, but it’s far from stagnant.  Guido always had a very clear 
vision of what Python should be, where it should go, and how new proposed 
features (or other changes to the Python ecosystem) fit into that vision, even 
if he didn’t or couldn’t always clearly articulate them.  The NBDFL will 
necessarily have a different vision than Guido, and I think even he would agree 
that that’s okay!  A strong vision is better than no vision.  Python must 
continue to grow and evolve if it is to stay relevant in a rapidly change 
technology environment.  As an almost 30 year old language, Python is already 
facing challenges; how will that vision address those challenges, even if to 
explicitly choose the status quo?

Will a council be able to articular, express, communicate, adapt, and follow 
through on that vision?  Will a council be able to evaluate a proposed change 
as it supports or detracts from that vision?  Will a council be able to break 
out of a primarily maintenance position, to actually move the language and its 
primary implementation forward?  I’m not so sure.

For these reasons I propose that we retain a singular BDFL.

The formation of a formal Council is still a good idea!  I just think that it 
shouldn’t be the ultimate arbiter of decisions for Python.  So what would the 
Council do?

- It would serve as a check on the BDFL.  If Bob Smith were one day employed by 
Evil Corp. and started making decisions that were directl

Re: [python-committers] An alternative governance model

[Barry Warsaw]

On Jul 17, 2018, at 22:55, Kushal Das  wrote:

> +1 to this idea including Brett as BDFL. Though I am wondering if
> anyone asked Brett about it?

I know my email was long, so easy to overlook, but I did ask Brett and he 
didn’t immediately say no.  :)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 01:43, Antoine Pitrou  wrote:
> 
> Why do you think non-BDFL projects have a problem with """ambiguity as
> to the authority of said decision"""?  What is your basis for that
> assertion?

With more people empowered to make a binding decision as part of a Supreme 
Council, there will be more uncertainty in the authority of the person 
pronouncing.  Part of that will be because the pronouncement can come from any 
of the member of the Council, and part may come from more turnover in the 
Council membership.  I’m not at all concerned about *us* accepting that 
authoritative decision because we are are deeply invested in Python’s 
governance.  But I claim that the vast majority of Python users are not, so 
while they recognize Guido’s name as the (former) leader, I question whether 
they will be able to have the same certainty in the authority of a decision 
coming from 3 or 5 people who’s names they are not familiar with.  With a 
singular leader, it will be easier to communicate the authority of that leader.

So yeah, maybe it’s a PR problem, but it’s still important nonetheless.

> I'm worried that you seem to be descending into magical thought,
> believing for some reason that nothing else than monarchy could ever
> work for a software project.

We’re not talking about software project governance in general, we’re talking 
about Python specifically. And Python has had a strong singular leader with a 
clear vision for its entire nearly 30 year life.  Yes, I personally question 
whether a Supreme Council will work for Python.

> Since you're opening this can of worms, I'll say it:
> 
> - I'm -1 on a new dictator-for-life (*)

Let me be clear: “BDFL” is a convenient term with a well-known meaning.  In 
fact, I believe *we* coined that term that’s now often used in other open 
source projects.  But as Guido has eloquently demonstrated, the “For Life” part 
really means “For As Long As They Want To Do It”.  In other words, it’s just a 
title for the job.  In my proposal, it really means “For As Long As They Want 
To Do It And They Don’t Do Something Evil Enough To Get Impeached”.  I’m 
spelling that title with the initialism “BDFL” :)

> - I'm -1 on Brett Cannon as a new dictator-for-life

Of one thing I have absolutely no doubt: no decision in Python will ever be 
unanimous!  That kind of proves my point as to why a singular leader is 
necessary. :)

> You're creating a huge problem here.  Whatever dictator you come up
> with, not everyone will be ok with that choice.  What are they supposed
> to do?  If one doesn't think X is legitimate as a dictator, how does one
> keep contributing to the project?  In other words, you are threatening
> to exclude people, perhaps seasoned contributors.

How is that any different with a Supreme Council rather than a singular leader? 
 Whatever makeup of the Council we come up with, not everyone will be okay with 
those choices.  What are they supposed to do?

Ultimately you’re right.  There are zillions of reasons not to contribute to 
Python, so having no confidence in its leadership is just one more.  
Fortunately, only you get to decide whether your reasons not to contribute 
outweigh your reasons to contribute.  And further, it’s open source, so you are 
*always* welcome to fork.  Look at Devuan 
.

>> I’ve long said — somewhat in jest, since I never expected Guido to actually 
>> ever retire! — that Brett would be my choice for the next BDFL.  I think 
>> he’s the perfect candidate, and he’s already demonstrated qualities that I 
>> think make him a fantastic leader.
> 
> I bed to disagree, Barry.  Brett is a good contributor, that doesn't
> make him legitimate as a dictator.  Only Guido could be, and he has
> stepped down.
> 
> The amount of cheerleading here ("""smart, compassionate, passionate,
> respectful, young, tall, and has the right mix of technical excellence
> and social skills""") is embarrassing.  What if we don't subscribe to
> your views of Brett's qualities: do you expect us to publicly criticize
> Brett so as to justify our opposition?

Also fortunately, I don’t get to unilaterally decide this!  I get to propose a 
plan, make my arguments, try to persuade, and cast my one vote — hopefully, 
depending on the criteria.  Just like all of you. :)

(Maybe we don’t count anybody who has more hair on his chin now than his head 
when he first started using Python, in which case, I’m definitely forking what 
I’ll call UncleTimmython).

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 02:49, Ethan Furman  wrote:

>> (*) (I'm leaving the "benevolent" part out, since clearly it was only
>> tied to Guido's personality, not to any inherent statutory limitations)
> 
> I think that's a mistake.  Clearly, the "benevolent" part is a major criteria 
> for the dictator, triumvirate, CoE, or whatever we come up with, and Guido is 
> not the only benevolent core-dev we have.

+1 - completely agree.  “Benevolence” is critical IMHO.

-Barry




signature.asc
Description: Message signed with OpenPGP
___
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] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 03:04, Antoine Pitrou  wrote:
> 
> If we're talking about a dictator (this is Barry's proposal), we're not
> talking about someone that just makes language design decisions, as
> Victor pointed out.

I’m talking about a singular leader who has the responsibility and vision to 
direct Python for as long as they are able and want to.  Just as Guido left 
tons of decisions to others (including this one :), so will the next BDFL.  
Exactly what that mix of delegation will look like is, in my proposal, up to 
the NBDFL.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 03:31, Ethan Furman  wrote:
> 
> I think this is the crux of the argument:  getting a group of people, even a 
> small one, to agree on a singular vision can be very difficult.

Yep.

>> I also think a council will be much more risk adverse than a singular BDFL, 
>> and that’s not necessarily a good thing.  While moratoriums and a more
> > conservative approach to change may be appropriate at times, I would prefer 
> > those to be deliberate decisions for a specific purpose, rather than
> > the unintended outcome of groupthink or lack of consensus.  A singular BDFL 
> > with support from the community will have more authority to make
> > decisions which probably will never be universally accepted, and much less 
> > prone to vapor lock due to lack of consensus or internal bickering.
> 
> Community support can be mercurial, and should not be relied upon as an 
> underpinning of our governance model.

No?  I think it’s critical.

Here’s a thought experiment: Pretend that PEP 572 were in front of the Supreme 
Council.  How do you think the discussions would go?  Would your opinion for or 
against be weighed with sufficient deliberation?  Would the PEP have undergone 
the rewrites it did in order to address the concerns early on?  Would you have 
confidence in the decision of the Council, whether it went your way or not?  If 
you lost the argument, how would you react?  How would any of that be different 
with a singular leader?  Would it matter to you if that leader was not Guido?

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 09:10, Antoine Pitrou  wrote:

> At this point we are not talking about a majority vote.  All I see is a
> rushed plebiscite on a single governance model and a single person.

Antoine, there’s nothing rushed about this.  I made a proposal, and there’s a 
healthy debate going on.  We don’t even know how the decisions will be made, or 
by whom yet.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 09:44, Steve Dower  wrote:

> Right now, I imagine Barry is testing the waters to see whether it's worth 
> his time writing this up as a proposed PEP 2. Other people seem to be 
> interested in also proposing alternative PEP 2s, and eventually we as a group 
> will have to select one of them, no doubt by majority vote. And while Barry's 
> long service to this group certainly adds weight to his opinion, it's also 
> likely that we can filibuster for long enough until he retires and then 
> ignore him completely :)

One can only hope! :)

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 10:13, Eric Snow  wrote:

> Regardless of when it happens (if ever), what will happen
> in the future when we don't have anyone suitable?  One danger is that
> we will install someone un-suitable because "we've always had a BDFL".
> But what is that "danger"?  What impact could a rogue BDFL have?

I’m not concerned about that, and not just because I’m secretly wishing for a 
filibuster until I get to join Guido on the Isle of Former Pythonistas Who Know 
Prefer To Sip Margaritas In Peace and Quiet and No Internet.

Grooming suitable future leaders is critical to the relevance of Python for the 
next 30 years.  I’m confident that when the time comes, there will be obvious 
choices, just as there has been for Release Managers.  And if there really 
isn’t then future archeologists will point to this thread and say “maybe now we 
can experiment with a Supreme Council”.

> 1. what makes a good BDFL?
> 2. what do we do when we can't find a suitable candidate?
> 3. what negative impact can a BDFL have?
> 4. how do we mitigate that impact?  how do we deal with a "bad" BDFL?

I’d like to add: how do we ensure that we will have many suitable candidates if 
and when the time comes to choose the N+1BDFL?

> However, I supposed I hadn't considered it before, but the BDFL has a
> much more significant role.  The Python community is in many ways a
> reflection of Guido and a result of his leadership (much more than
> technical leadership).  Consequently, a new BDFL must be someone who
> reflects where we want the community to be.

To me, that’s the “vision” question, but I think the BDFL doesn’t just reflect 
the communities wishes, because “the community” will never agree 100% on 
anything.  Which, FTR, I think is okay.  The BDFL uses their intuition, 
compassion, and experience to move Python forward according to their vision for 
what the language should be, deeply informed by —but not subservient to— the 
opinions of all its users and developers, because that’s essentially impossible.

> 2. what do we do when we can't find a suitable candidate?
> 
> This is worth figuring out.  It isn't something we've discussed much.
> I expect most folks feel like it will never be an issue.  I suppose
> they're right.  At the point there isn't a suitable candidate, we have
> larger problems to address. :)

Indeed.  I’d say that we should be proactive so that we never get into that 
position, by beginning to groom future NBDFLs now.

> 3. what negative impact can a BDFL have?
> 
> I was primarily thinking about a "rogue" BDFL, rather that about
> mistakes an otherwise good one might make.  The big question is what
> does it mean for the BDFL to go "rogue".  It definitely isn't "making
> a decision the people don't agree with" as Guido has done that plenty
> of times (to our benefit). :)  In my mind, the main bad that the BDFL
> can do is to hurt the community.  Their possible negative technical
> impact is small and highly recoverable.

That’s a good point, except that there is usually a window of practical 
recoverability.  For example, once Python 3.8 is released, PEP 572 will be very 
very difficult to undo.

> 4. how do we mitigate that impact?  how do we deal with a "bad" BDFL?
> 
> People make mistakes.  We should expect the BDFL to make them too.  We
> should also expect them to care deeply about Python (as well as align
> relatively closely with the community).  We can deal with their
> mistakes. :)
> 
> However, if the BDFL turns out to be not as capable as we expected (no
> judgement, Brett) or appears to be purposefully hurting Python then
> we'd need to act.  On the one hand we'd need to deal with the BDFL
> directly, likely replacing them or more broadly restructuring.  On the
> other had we'd have to deal with the community consequences (the four
> listed in point #3).  The latter is the one with deeper consequences.
> TBH, the same is true of any structure we apply (e.g. council,
> majority rule).
> 
> I suppose the most we could plan for would be quickly removing a rogue
> BDFL (but without such a plan hanging over a good BDFL's head).  I'd
> consider Barry's proposal of advisers to be in the right direction.
> That said, as with #2 this is probably not something that will ever
> come up.

Thanks Eric, these are good points to consider.

> The "benevolent" part is critical though.  Without it none of the rest
> would work for us.  Perhaps I've misunderstood your point?  FWIW, the
> word "dictator" has a lot of negative connotation that does not match
> our usage in BDFL.  I don't mean to suggest that's the only concern
> here, but would it help to use a different name than BDFL?  IIRC, it's
> either a clever Monty Python reference or a tongue-in-cheek expression
> from Barry 20 years ago that stuck.

I’d put my money on Uncle Timmy coining that term, but maybe you’re on to 
something here.  Okay, let’s call our leader “Dinsdale”.  As in, who will be 
the Next Dinsdale?

> Fair enough.  I don't mea

Re: [python-committers] Language moratorium

[Barry Warsaw]

On Jul 18, 2018, at 09:11, Stefan Krah  wrote:

> if I remember correctly, we had a moratorium for language changes around
> versions 3.2-3.3.  I think during that time relatively few BDFL-level
> decisions were required.
> 
> Perhaps we could have one again, say for 12 months so we can figure things
> out. Other Python implementations may welcome the moratorium so they can
> catch up.

I agree that we’ll effectively have language moratorium until we have a new 
governance structure.  But let me ask, what do you propose to do about PEP 572? 
 That’s already been accepted, but not yet implemented.  Would it be exempt 
from the moratorium or scoot in under the wire?

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 16:06, Fred Drake  wrote:

> PEP 2 is (currently) the "Procedure for Adding New Modules".  Though
> superseded, recycling the PEP number seems out of character with the
> RFC process from which we derived the PEP process.  Let's be cautious
> about recycling like that; integers are cheap.

Dang, so it is.  :(

I don’t want to recycle numbers, so we’ll likely end up taking the next 
available low ones.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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

[Barry Warsaw]

On Jul 19, 2018, at 10:19, Terry Reedy  wrote:
> 
> On 7/19/2018 1:10 PM, Mariatta Wijaya wrote:
>> On Thu, Jul 19, 2018 at 8:59 AM Brett Cannon > > wrote:
>> So what about the following timelines:
>> Oct 1: Deadline for people to come up with proposals of governance model, 
>> candidates, and how to vote
>> Dec 1: Deadline to choose a governance model, (and if possible, we choose 
>> the new leader(s) too)
> 
> Why not Nov 1, leaving a month to decide on proposals?
> 
>> Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec 1.

I like the Nov 1 schedule.  I’m +1 with giving plenty of time to process, but I 
share the concern about letting things drag on too long.

IMHO, ideally we’d have the new governance structure and its office holders in 
place by EOY18.  That has to account for various holidays, including 
Thanksgiving in the US and Christmas to New Years.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Language moratorium

[Barry Warsaw]

On Jul 19, 2018, at 08:41, Brett Cannon  wrote:
> 
> Then we would have to solve our governance problem sooner rather than later. 
> But i don't think every Python release has to make a huge splash.

The other option of course is to push the release date of Python 3.8 back to 
accommodate the new governance structure.

> On Jul 18, 2018, at 19:23, Tim Peters  wrote:

> Unsure!  Governance is needed to resolve conflict.  When there's broad 
> agreement, "leaders" aren't really needed.  For example, there's been a bit 
> of talk on python-ideas about adding a new `intmath` module capturing some 
> frequently reinvented functions for which decent implementations are known 
> but non-obvious (e.g., for generating the primes).  Nobody could sanely fight 
> to death against something like that.  Even whining about it would appear 
> petty ;-)


I don’t necessarily include new modules, other stdlib changes, build or 
performance improvements, and other such “normal development” work (i.e. bug 
fixing) to be affected by a language moratorium.  PEP 572-level decisions would 
very definitely fall under that rubric.

We have plenty of experts still in place that can make more minor decisions.  
In fact, perhaps we should largely operate as if our BDFL were just on a long 
vacation and not pronouncing on PEPs.  That’s never frozen Python development 
before, and shouldn’t now.

If PEP 572 were the only new syntax for 3.8, then so be it.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 17:31, Alex Martelli via python-committers 
 wrote:
> Humans do so love to argue!
> 
> No we don't! (cfr http://www.montypython.net/scripts/argument.php)...

I guess that means we do love getting hit on the head…

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] And Now for Something Completely Different

[Barry Warsaw]

On Jul 20, 2018, at 00:49, Antoine Pitrou  wrote:
> 
> I find the PEP-delegate to be a powerful concept.  Why wouldn't *every*
> PEP have a PEP-delegate?  This way we don't need a BDFL anymore.  We can
> discuss how to nominate PEP-delegates (Nick had an interesting proposal).

Because IMHO that would lead to a language designed by committee, with a less 
consistent vision.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Reminder of BDFL succession timeline + CFP

[Barry Warsaw]

On Aug 1, 2018, at 12:41, Mariatta Wijaya  wrote:
> 
> Since this is like a CFP I figured we should clarify what's expected the 
> proposal, and I also wanted to be more detailed in the timeline.
> 
> Oct 1 00:00:00 UTC: Deadline of coming up with proposals of governance model.

Thanks for writing this up Mariatta.  I think it’s very useful to put stakes in 
the ground so that these discussions don’t drag on forever.  I agree with those 
who say that the status quo is an implicit choice of governance models, and I 
think we shouldn’t operate under implicit rules for too long.  Like Brett, I 
often have folks coming up to me and asking me what’s going on, and when Python 
will decide on a governance model.  Let’s not underestimate the message this 
sends to the outside world.

OTOH, we do have some flexibility in the timeline, and I still believe that we 
have flexibility in the governance model over the long term.  I’ve no doubt 
that no matter what we choose, the debate will continue, with ebbs and flows as 
situations arise.  That may even lead to new (or adjusted) governance models in 
the future, and that’s fine!  Unlike with Python itself, we aren’t bound to 
strict backward compatibility. :)

That said, I think it’s worthwhile capturing the proposed governance models in 
PEPs so that we all know exactly what we’re debating.  October 1st for that 
round of PEP submissions is quite reasonable IMHO.  Procedurally, I suggest we 
segregate governance model PEPs in their own 4th digit namespace (e.g. like the 
way Python 3k started at the 3000s).  8 seems like a good number; we reserve 
the lower 8ks for “special” PEPs (the problem statement, the choice, the voting 
procedure, etc.).

We can be a little more loose on the voting schedule, but like Brett, I would 
like to have a decision by the end of 2018, even if that decision is an 
explicit choice of status quo.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] 1 week to Oct 1

[Barry Warsaw]

On Sep 24, 2018, at 14:32, Mariatta Wijaya  wrote:
> 
> 1. Is everyone still ok with the Oct 1 as deadline for coming up with 
> governance PEPs?

I’m afraid that I may not be, actually.  I expected to have time to work on my 
PEP while I was on leave for my son’s wedding, but y’know, family! :)  Mariatta 
and I are collaborating a bit on 8011, but I haven’t really had time to work on 
8010.  I don’t want to push it back too far, but a couple of weeks would really 
help.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Council / board (Was: 1 week to Oct 1)

[Barry Warsaw]

On Sep 25, 2018, at 14:40, Brett Cannon  wrote:

> For me personally, I am not going to participate in any discussion about any 
> PEP until there is a published text to refer to, otherwise the discussion is 
> ripe for misunderstandings. If a PEP comes out which people disagree with and 
> want an alternative for I'm sure we can give them an opportunity to create a 
> tweaked PEP (but I also assume we will have a civil discussion first in hopes 
> of finding consensus first).

Agreed.  Also, something we discussed at the sprints was the idea of each of 
the general governing PEPs will have certain knobs that can be tweaked.  E.g. 
the exact number of folks on a committee, or their term limits, etc.  It’s 
probably counterproductive to have competing PEPs that differ only in some of 
these details.  Ultimately, it’s up to the PEP authors, but I think we’ll come 
to consensus much more quickly when we can use the PEPs to describe the general 
shape of governance, and work the details out in the subsequent conversations.  
At least, that’s how I see it working for the PEP I’ve promised to author.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Python 4.0 or Python 3.10?

[Barry Warsaw]

On Sep 25, 2018, at 15:31, Antoine Pitrou  wrote:
> 
> So my preference would be on 3.10.

3.9 + 0.1 :)

Renaming it to Python 4 is fraught with knock-on effects, so I think we do 
reserve that for major changes.  I doubt we’ll ever need for a disruptive 
backward incompatible change *at the Python level* in a Python 4, but I 
absolutely can see the possibility of incompatible changes at the public C API 
layer.  I’m not saying it *will* happen, but that’s what we should reserve 
“Python 4” for if or when it happens.

-Barry





signature.asc
Description: Message signed with OpenPGP
___
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] Python 4.0 or Python 3.10?

[Barry Warsaw]

On Sep 25, 2018, at 18:57, Victor Stinner  wrote:
> 
> IMHO It's time to discuss again modifying the "python" program to always 
> point to the latest Python version.

This just came up again on linux-sig, but...

> What is the status of Brett's UNIX Python launcher "py" by the way?

...I forgot to mention this.

FWIW, I still think we shouldn’t recommend a change here until 2.7 is done and 
done.  However, the launcher might be a good way out.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] 1 week to Oct 1

[Barry Warsaw]

On Sep 26, 2018, at 19:28, Mariatta Wijaya  wrote:
> 
> Really sorry folks, but I also would like to request an extension, by one 
> week to Oct 8.
> It's not because I've been slacking; I've started a five-page document (only 
> Barry has seen it), but I still need his help before it can be ready for the 
> public.
> In addition, I'm facing personal health issue. I'll be unable to work on the 
> proposal for the next few days.

+1 - I just got back from a whirlwind three weeks of the core sprint followed 
by my son’s wedding.  I did get a chance to start fleshing out PEP 8010, but I 
have a lot of catching up to do, plus two talks to give by October 1st, so a 
week’s delay would be very helpful.  I don’t think I’ll need more than that.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] python-committers is dead, long live discuss.python.org

[Barry Warsaw]

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 out with Gmane if there's interest.

Yes, I use NNTP to read many of the Python mailing lists.  Gmane, even in its 
current state, is fantastic.

I’m all for supporting the next generation of developers, but not necessarily 
at the expense of *decades* of established workflow for current developers.  
Moving to Discourse breaks this and proliferates browser tab syndrome.  It’s an 
experiment worth conducting, but I do think it’s a bit cavalier to shut down 
python-committers without further discussion.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] python-committers is dead, long live discuss.python.org

[Barry Warsaw]

On Sep 28, 2018, at 15:03, Victor Stinner  wrote:

> It seems like anyone can subscribe. Is the Committer group reserved to
> core developers? If yes, how do you know which accounts are linked to
> core developers?

You must be approved to join python-committers, but its archive is public for 
anyone to read.  Does Discourse provide the same level of access for core 
developers and non-core developers?

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Please wait for my governance PEP

[Barry Warsaw]

I am planning on finishing up 8010 tomorrow and doing a check in of the initial 
draft.  Happy to have collaborators!

-Barry

> On Oct 4, 2018, at 06:18, Łukasz Langa  wrote:
> 
> There are already three published PEPs:
> - PEP 8012: discussion on 
> https://discuss.python.org/t/pep-8012-the-community-model/156/5
> - PEP 8013: some discussion here
> - PEP 8014: no discussion yet
> 
> I expect PEP 8010 and PEP 8011 to be done by the deadline which was extended 
> to October 8. You are free to write your own PEP but you might save 
> significant effort and time by looking at the existing ones and teaming up 
> with one of them. You can reach out to Mariatta or Barry to learn how far 
> along they are.
> 
> I know I'd be very happy to have you help with PEP 8012 :-)
> 
> --
> Best regards,
> Łukasz Langa
> 
> 
> On Oct 4, 2018, at 15:02, Victor Stinner  wrote:
> 
>> Hi,
>> 
>> I was waiting for other governance PEPs to decide if I would write
>> mine or not. Since I don't see other PEPs, I decided that I will write
>> mine. Please give me between one and three weeks to write it.
>> 
>> Note: Sorry, I didn't follow the Discourse discussion, I'm not sure if
>> this mailing list should be used or not.
>> 
>> 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/



signature.asc
Description: Message signed with OpenPGP
___
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] Timeline to vote for a governance PEP

[Barry Warsaw]

On Nov 2, 2018, at 20:24, Tim Peters  wrote:

> Nevertheless, I probably won't vote - I object to public ballots on
> principle.  That's been raised by others, so I won't repeat the
> arguments, and I appear to be very much in a minority here.

I also prefer private ballots on principle, but I’ll still vote if they are 
public.  I don’t completely buy into the rationale in PEP 8001 on why they must 
be public.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Timeline to vote for a governance PEP

[Barry Warsaw]

On Nov 5, 2018, at 11:10, Brett Cannon  wrote:

> It's outdated. I think Barry just hasn't thought of updating it yet since 
> it's just an index into the 801X PEPs which you can view in the PEP index 
> directly without any special background info (I know I personally forgot that 
> PEP 8000 even listed the various PEPs).

I just updated the PEP 8010 description in PEP 8000.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Timeline to vote for a governance PEP

[Barry Warsaw]

Based on my suggestion on Discourse, I propose that the period between tomorrow 
and November 30th be an official PEP review period, with voting postponed to 
December 1 - 16 AOE 2018.

https://github.com/python/peps/pull/841

I am personally going to start reviewing these PEPs after the flood of 
trypophan is unleashed into my bloodstream following the USA Thanksgiving meal.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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 we choose between mailing list and discuss.python.org?

[Barry Warsaw]

On Feb 11, 2019, at 09:48, Victor Stinner  wrote:
> 
> tl; dr How can we decide if we should stop using mailing list or if we
> should stop using discuss.python.org?

Point of order: I think we need a PEP for this decision.  Such a PEP would 
organize and consolidate the arguments both pro and con of the three choices.  
It should also cover whether the current Discourse experiment translates to 
larger mailing lists like python-dev, -ideas, and -list (for which I personally 
have uncertainty about).

Once that PEP is written, the SC is the proper forum for deciding the next 
steps, IMHO.

-Barry




signature.asc
Description: Message signed with OpenPGP
___
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 we choose between mailing list and discuss.python.org?

[Barry Warsaw]

On Feb 12, 2019, at 13:59, Antoine Pitrou  wrote:

> I know I can browse easily through a 161-message mailing-list or
> newsgroup thread using a traditional threaded view, read what I want,
> come back later to read the rest, etc.  But Discourse's linear
> presentation pretty much kills that ability.  It doesn't even allow
> *seeing* the structure of the discussion.

That’s pretty much my same, biggest gripe about long GitHub issues and PRs. ;)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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 we choose between mailing list and discuss.python.org?

[Barry Warsaw]

On Feb 12, 2019, at 18:01, Ned Deily  wrote:
> 
> On Feb 12, 2019, at 20:36, Barry Warsaw  wrote:
>> On Feb 12, 2019, at 13:59, Antoine Pitrou  wrote:
>> I know I can browse easily through a 161-message mailing-list or
>>> newsgroup thread using a traditional threaded view, read what I want,
>>> come back later to read the rest, etc.  But Discourse's linear
>>> presentation pretty much kills that ability.  It doesn't even allow
>>> *seeing* the structure of the discussion.
>> That’s pretty much my same, biggest gripe about long GitHub issues and PRs. 
>> ;)
> 
> But you realize that this a feature, not a bug? :)
> 
> https://blog.codinghorror.com/web-discussions-flat-by-design/

Unfortunately, that post doesn’t talk about all the problems with flat 
discussions, and there are many.  So if we have to, we can agree that both have 
advantages and disadvantages, both have their proponents and detractors, and 
very likely both are appropriate to some forums and discussions and 
inappropriate (or ineffective) for others.  Or maybe more succinctly: both are 
terrible. ;)

That tells me either that the problem is fundamentally unsolvable due to the 
nature of online discussions, or we’re asking the wrong questions.

As far as software darwinism is concerned, we can also admit that top posting 
has won, but not necessarily because it’s superior (in fact, IMHO it’s not).  
It’s just that mobile and webmail has taken over and either because of laziness 
or U/I difficulties, inline replies are too difficult.

We live with plenty of inferior technology for reasons that aren’t entirely 
based on actual efficiency and ease of use.  Techmology! (with apologies to Ali 
G).

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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 we choose between mailing list and discuss.python.org?

[Barry Warsaw]

On Feb 13, 2019, at 15:13, Victor Stinner  wrote:
> 
> I only asked *how can we take a decision*?

We start with a PEP, then the SC will make a determination based on this PEP 13 
Mandate:

"Establish appropriate decision-making processes for PEPs”

which is still a work in progress.  I think for the short term, we just 
continue the status quo.  It’s not ideal to have two forums for the same 
community, but it’s not such a burden that it needs immediate resolution, IMHO.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Steering Council Update for April 2019

[Barry Warsaw]

On Apr 26, 2019, at 09:12, Berker Peksağ  wrote:

> I don't think there was a consensus on switching to GitHub Issues last
> time it was discussed. The most recent discussion about PEP 581 only
> has 12 messages. I think the council is making a premature decision
> here.

Technically speaking, the PEP is still in Draft state.  I have a PR up for 
splitting the migration into two separate PEPs, one for the rationale and a 
second one for the migration plan:

https://github.com/python/peps/pull/1013

> I'm strongly against using GitHub Issues. I will change my mind once I
> see a sign that GitHub is actually listening to our feedback. We can't
> even get them to make the use of # and GH- in the commit title
> configurable (https://github.com/maintainers/early-access-feedback/issues/77)
> and have the ability to automatically strip intermediate commit
> messages from the commit message body
> (https://github.com/maintainers/early-access-feedback/issues/153) The
> only time I got a response from them was this:
> https://github.com/python/miss-islington/issues/16#issuecomment-396095622

It would be very helpful if you could add these comments to the PR.

> I volunteered to maintain our Roundup instance a while ago and already
> fixed some bugs: https://hg.python.org/tracker/python-dev/ I've also
> submit patches to improve UX and fix issues. I'd list list them here
> but I can't reach out to http://psf.upfronthosting.co.za/roundup/ at
> the moment. I hope the problem with the hosting is temporary because I
> have several non-trivial patches there.

And as a fan of Roundup and its critical importance to the Python development 
process, I want to personally thank you for all your —and everyone who has 
contributed to it over the years— hard work in maintaining it.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Promote Mark Sapiro and Abhilash Raj as core developers

[Barry Warsaw]

If you like the way mail.python.org and Mailman (both 2 and 3) Just Work, and 
are about as reliable as any service can be, we have our wonderful postmasters 
to thank.  Mark has been a postmaster for years and is currently maintaining 
GNU Mailman, both as a project and as a service on mpo.  Abhilash maintains the 
GNU Mailman 3 branch, has been project leader since I retired in that role back 
in 2017, and also maintains the Mailman 3 instance on mail.python.org.

More than that, because of their roles as Mailman developers, they have a deep 
knowledge of email in general, and in the email package in particular.  As I 
rarely dabble in the email package these days, and RDM --who did a fantastic 
job of implementing the new APIs and features in email for Python 3— has also 
scaled back his involvement, it means that the email package doesn’t get much 
attention these days.  Both Mark and Abhilash have an interest in helping to 
maintain the email package moving forward, and both are eminently qualified to 
do so.

I have worked with both of them for many many years, and I have the utmost 
respect for their technical and social skills, their understanding of Python 
processes, and their love of the Python language and community.  I've sprinted 
with them at many Pycons, until I scaled back my involvement with Mailman.  
Both are here sprinting at Pycon 2019.

Therefore, with their permission, I propose extending core developer rights to 
both Mark and Abhilash.

As per PEP 13, I plan on opening a vote on Discourse next week (once I kind of 
recover from Pycon) for each developer.

Cheers,
-Barry




signature.asc
Description: Message signed with OpenPGP
___
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 Mark Sapiro and Abhilash Raj as core developers

[Barry Warsaw]

On May 13, 2019, at 01:14, Victor Stinner  wrote:

> I'm no longer sure myself that I can define them. I prefer to repeat
> what others say :-) Basically, a core developers is someone who
> produces commits :-) That's one definition.

But, IMHO not a correct one.  The full quote from PEP 13:

——snip snip——
Python core team members demonstrate:

• a good grasp of the philosophy of the Python Project
• a solid track record of being constructive and helpful
• significant contributions to the project's goals, in any form
• willingness to dedicate some time to improving Python

As the project matures, contributions go beyond code. Here's an incomplete list 
of areas where contributions may be considered for joining the core team, in no 
particular order:

• Working on community management and outreach
• Providing support on the mailing lists and on IRC
• Triaging tickets
• Writing patches (code, docs, or tests)
• Reviewing patches (code, docs, or tests)
• Participating in design decisions
• Providing expertise in a particular domain (security, i18n, etc.)
• Managing the continuous integration infrastructure
• Managing the servers (website, tracker, documentation, etc.)
• Maintaining related projects (alternative interpreters, core infrastructure 
like packaging, etc.)
• Creating visual designs

Core team membership acknowledges sustained and valuable efforts that align 
well with the philosophy and the goals of the Python project.
——snip snip——

I’m quite convinced that both Mark and Abhilash meet these requirements.  And 
they are almost by definition the experts in the email package.  You can 
certainly see the nature of their work in the Mailman repos, and I would be 
willing to mentor them through the first few commits to the CPython repo, 
though I think it will be mostly perfunctory.

> Having a sustainable Mailman project is great. But how does that
> relate to Python itself? Are you talking about the email module? Do
> Mark Sapiro and Abhilash Raj plan to maintain the email module?

Yes, that is the intent.

> In the meanwhile, they don't have to be core devs to help to maintain
> the email module, no?

Do we have any core developers who want to maintain it?  Not me :) and 
apparently not RDM.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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 Mark Sapiro and Abhilash Raj as core developers

[Barry Warsaw]

On May 14, 2019, at 00:46, Antoine Pitrou  wrote:

> Barry, if you trust
> Mark's and Abhilash's competence, it should probably be easy for you to
> merge their first PRs (and guide them along the way).

I do, and that works for me.   Can we give them triage rights on bpo now?

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] PEP 581 (Using GitHub issues for CPython) is accepted

[Barry Warsaw]

As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of 
the Steering Council, I hereby Accept this PEP.

We would like to thank Mariatta for championing PEP 581, and to all the 
contributors to the discussion, both pro and con.  We appreciate your candor 
and respect for your fellow developers.  The SC believes that this migration is 
in the best interest of the Python community, and we look forward to the 
elaboration of the detailed migration plan (PEP 588).

We also extend our heartfelt thanks Berker, Ezio, and everyone who has helped 
develop and maintain Roundup and bugs.python.org over the years.  bpo has been 
a critical component for Python development for a very long time, and we all 
greatly appreciate the time, effort, and devotion you have put into this 
resource.

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

Onward we go!  The migration will be a large effort, with much planning, 
development, and testing, and we welcome volunteers who wish to help make it a 
reality.  I look forward to your contributions on PEP 588 and the actual work 
of migrating issues to GitHub.

Cheers,
-Barry (BDFL-Delegate, and on behalf of the Python Steering Council)



signature.asc
Description: Message signed with OpenPGP
___
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] Re: [RELEASE] Python 3.8.0b2 is now available for testing

[Barry Warsaw]

I’ve updated the official images to include 3.8.0b2:

https://gitlab.com/python-devs/ci-images/tree/master

Cheers,
-Barry

> On Jul 4, 2019, at 15:05, Łukasz Langa  wrote:
> 
> Signed PGP part
> After a few days of delay, but somewhat cutely timed with the US Independence 
> Day, I present you Python 3.8.0b2:
> 
> https://www.python.org/downloads/release/python-380b2/ 
> 
> 
> This release is the second of four planned beta release previews. Beta 
> release previews are intended to give the wider community the opportunity to 
> test new features and bug fixes and to prepare their projects to support the 
> new feature release. The next pre-release of Python 3.8 will be 3.8.0b3, 
> currently scheduled for 2019-07-29.
> 
> Call to action
> 
> We strongly encourage maintainers of third-party Python projects to test with 
> 3.8 during the beta phase and report issues found to the Python bug tracker 
>  as soon as possible. While the release is planned 
> to be feature complete entering the beta phase, it is possible that features 
> may be modified or, in rare cases, deleted up until the start of the release 
> candidate phase (2019-09-30). Our goal is have no ABI changes after beta 3 
> and no code changes after 3.8.0rc1, the release candidate. To achieve that, 
> it will be extremely important to get as much exposure for 3.8 as possible 
> during the beta phase.
> 
> Please keep in mind that this is a preview release and its use is not 
> recommended for production environments.
> 
> No more non-bugfixes allowed on the “3.8” branch
> 
> The time has come, team. Please help make Python 3.8 as stable as possible 
> and keep all features not currently landed for Python 3.9. Don’t fret, it’ll 
> come faster than you think.
> 
> 
> - Ł
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
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/JRX5LSDAUVU6JELT26WACVNGVDSIGZNK/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Promote Abhilash Raj to core developer

[Barry Warsaw]

I have just posted a poll to Discourse proposing to promote Abhilash Raj to 
core developer status.

https://discuss.python.org/t/vote-to-promote-abhilash-raj-as-core-developer/2041

The topic includes his background, my endorsement, and a list of contributions 
to CPython.  I hope that you will vote to confirm him as a core developer.  He 
will be an excellent addition to our team.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/J7U5PAGTQ7E2RJMNL6RTE4EISQ6QQBTF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Barry Warsaw]

I have updated the official docker images with 3.8b3:

https://gitlab.com/python-devs/ci-images/tree/master

-Barry

> On Jul 29, 2019, at 14:48, Łukasz Langa  wrote:
> 
> Signed PGP part
> This time without delays, I present you Python 3.8.0b3:
> 
> https://www.python.org/downloads/release/python-380b3/



signature.asc
Description: Message signed with OpenPGP
___
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/2T7AXF4D7KIQML5QDNBX7I5KQWJOPKE3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Barry Warsaw]

Congratulations and welcome Abhilash!  Thanks Brett for setting him up, and 
thanks everyone who voted.

-Barry

> On Aug 6, 2019, at 14:19, Brett Cannon  wrote:
> 
> Assuming I didn't mess anything up, Abhilash is now set up!
> ___
> 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/7DCE4DR7FNLAWXQSNEBRSGOMFOVGKK3F/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
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/QM25LIFW43T6ODHEK5BK75NMCHAGQO3G/
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Barry Warsaw]

On Aug 6, 2019, at 15:27, Paul Moore  wrote:
> 
> (BTW, I didn't see an announcement of the closing of the vote and the
> final result on Discourse - did it get announced there?)

The vote closed automatically after one week, as per PEP 13.  However, I was 
traveling and haven’t had a chance to follow up to that Discourse thread yet.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/RQQMXS2F3MIZCZ26S2HDORKSMXLUQC6N/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] PEP 1: Relaxing the requirements for being a PEP sponsor

[Barry Warsaw]

PEP 1 currently says that if a PEP is authored by a non-core developer, the 
author must find a core developer to sponsor their PEP.  At today’s Steering 
Council meeting, we proposed to relax this requirement to allow non-core 
developers to sponsor a PEP with the approval of the Council.  There is no 
change if the PEP author is a core developer; in that case the PEP still does 
not require a sponsor.

Here is the PR with the proposed language change:

https://github.com/python/peps/pull/1170

Feel free to weigh in on the PR.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/FUVBANJTHMUC4X7N2H6ELUHAHOXDONPZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Barry Warsaw]

On Dec 11, 2019, at 02:28, M.-A. Lemburg  wrote:

> I'm sorry, but I had not expected to be delisted and thus did not
> check the voters list.

I didn’t expect to be delisted either but I’m sufficiently paranoid to have 
double checked that I was still on the voter list.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/E2BWZFOGAWTCWJFPLQ6CAQVTER36PX5O/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: A urlparse regression in minor version

[Barry Warsaw]

On Feb 11, 2020, at 05:26, Łukasz Langa  wrote:
> 
> I'll let others voice their opinions but my intuition for 3.8.x is to leave 
> your patch be. True, it should not have been backported but it was, and it 
> was already released as part of 3.8.1 and now 3.8.2rc1.

I don’t think you should worry about 3.8.2rc1.  That’s not a release version so 
shouldn’t impact the decision IMHO.

Whether 3.8.1 is important enough not to revert this change is an RM decision.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/A3OWT4ZPL3V233DXNULCF4AZE25QMSZ5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: A urlparse regression in minor version

[Barry Warsaw]

On Feb 16, 2020, at 10:20, Ned Deily  wrote:

> Rather than continuing this change in 3.9 introducing yet another, even more 
> unexpected behavior, I think we should first try to address what appears to 
> me to be the (a?) root cause issue: urlparse's API is not suited for parsing 
> both strictly RFC-compliant URLs (which are clearly not well-understood) 
> *and* today's schemeless URLs as have evolved over the years to become the 
> most commonly encountered form of URL.  Users want and need both.  The merged 
> change makes the previous situation worse, IMHO.

ISTM that the tension between doing the right thing and keeping backward 
compatibility should be explored through the addition of a new function with 
the intended semantics, or at least a new parameter (keyword-only?) that 
controls the behavior.  I don’t like the latter as much, but if you really want 
to keep a single functional interface, that would be a way to do it.

I don’t agree that it’s obviously okay to introduce a backward incompatible 
default behavior in 3.9.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/3I5Q2PQ4BFJSUFTUIO7ELNE6HIW3QVIK/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Language Summit

[Barry Warsaw]

You should definitely finish your PEP!

-Barry

> On Apr 15, 2020, at 16:40, Eric V. Smith  wrote:
> 
> 
>> I am reliant on summaries and anyone attending posting details.  Everyone 
>> please share your slides if you have any that are meaningful without a talk 
>> to go with them. At least to this committers list or discourse forum.  I 
>> expect I feel just like all of our non-travel-enabled colleagues who feel 
>> left out on a recurring basis.  =)
>> 
> Hi, Greg.
> 
> Here are the slides from my talk: 
> https://github.com/ericvsmith/f-strings-by-default/raw/master/F-strings%20everywhere!.pdf
> 
> I can't decide if it's worth continuing my work on a PEP. I need to re-read 
> and consider the various questions and suggestions from today. Thanks, 
> everyone, for your input.
> 
> Eric
> 
> 
> 
> ___
> 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/CIT3S7JAZJ4OZ3YD6LO77HZRMPQBRBVU/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
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/HPMDSNO427N2SR3FVGY6LVBQEXKGHAYU/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Please welcome our next Release Manager, Pablo!

[Barry Warsaw]

In light of the release of Python 3.9b1, let’s take a moment to celebrate all 
the great work that our Python 3.8 and 3.9 release manager Łukasz has done.  
The role of Python Release Manager is hugely important to each successful 
release, and it can be a lot of work, often unseen and thankless to shepherd a 
new Python version through its first alpha release to its last security 
release.  With all of your immeasurable help, the Release Manager ensures 
solid, feature-full releases that the entire Python community eagerly awaits.

Łukasz carries on the fine tradition of all of our past release managers, and 
now that his second release has entered beta phase, I’m very happy to announce 
our next Release Manager, for Python 3.10 and 3.11: Pablo Galindo Salgado!

Since becoming a core developer in 2018, Pablo has contributed significantly to 
Python.  With the change to an annual release cycle (PEP 602, authored by 
Łukasz), the time commitment for release managers has been reduced as well, and 
we will continue to look for ways to make the selection process for release 
managers more transparent and accessible.  I know that in addition to admirably 
managing the releases for 3.10 and 3.11, Pablo will also help to continually 
improve the process of selecting and serving as release manager.

Please join me in welcoming Pablo in his new role!

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/44TLJO5YX6XYM4ICWSHMBMCKPBBQQP5S/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Please avoid non-bugfix changes during the beta phase

[Barry Warsaw]

It’s true that as releases get closer to final, more people will start 
exercising them.  However, you really don’t have to wait.  I maintain 
“official” Linux (Ubuntu) Docker images that contain all the latest releases 
(including alphas and betas), and the git head of the development branch at the 
time of the image builds.

https://gitlab.com/python-devs/ci-images/-/tree/master

I keep these up-to-date on every new maintenance release, alpha, beta, rc, and 
final, for Python 2.7, and 3.4 through 3.10.  I use this image in my own open 
source code’s CI, and you can too!  Unfortunately, we can’t do the same with 
Windows, but I’ve cracked the nut to get pretty good coverage for Windows 
releases too.  Here for example is flufl.lock’s .gitlab-ci.yml file:

https://gitlab.com/warsaw/flufl.lock/-/blob/master/.gitlab-ci.yml

I need to extend that to 3.9 pre-releases, via python.org downloads rather than 
nuget.

So, it’s entirely possible to test your stuff against pre-release versions, and 
I highly encourage it.

That said, I also think that the general rule of only bug fix changes post beta 
1 is the right policy.  For other changes, or anything that you think straddles 
the line between bug fix and non-bug fix, ask the Release Manager.  The RM’s 
primary role at this time is to ensure the stability of the final release.  
Their judgement is critical to the success of the final release, so ask!  CC 
the RM on the PR and request their approval and comment.

I’ll also say that I personally give the RM a lot of latitude and authority to 
unilaterally revert any change they are not comfortable with.  If the change 
author and RM cannot agree on whether a post-beta change is appropriate, you 
can escalate to the Steering Council.

Cheers,
-Barry

> On Jul 6, 2020, at 19:21, Raymond Hettinger  
> wrote:
> 
> My two cents: I think this should be a little more liberal. At beta 1, freeze 
> the addition of new features but continue to tweak the implementation with 
> code clean-ups, additional tests, algorithmic improvements, and better docs.  
> For many of the devs (and users), the first time we get to exercise and 
> interact with some of the new features is during the beta — that is our 
> chance to improve and stabilize it before it goes out the door.  If a new API 
> proves awkward in some way, the time to find out and improve it is during the 
> beta.  Ideally, we would like both the API and implementation to mature a bit 
> before the release (first draft != final copy).  A release candidate is 
> different — that is close to an across-the-board freeze.  Once the release 
> happens, bug fixes and documentation tweaks will continue to be checked in 
> for the next micro-release.
> 
> Side note: One problem we have is that so few people actually exercise the 
> beta and give useful feedback.  To me, the chief value of a public beta is 
> that people get to try it out before everything is set it stone.  And reason 
> for having multiple betas is so that we can iterate.  If not, perhaps we 
> should just have a single beta, frozen except for bugfixes.
> 
> 
> Raymond
> 
> ___
> 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/EIXKURQS4HXHLMJM4LRIXODMJPON5SFR/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
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/HRQWCVDHI4IPHO6UXJ4QT7YHQWU2X77N/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Barry Warsaw]

Hello Ivan,

As mentioned, this was sent to python-committers, i.e. all core developers.  
The Steering Council, Conduct WG, and PSF Board have been working incredibly 
diligently on this incident for quite some time.  Remember that almost all of 
us are volunteers too!

We have tried to balance transparency and communication with respecting the 
privacy and reputation of the individuals involved, including the banned member 
and members who were reprimanded but not banned.  We tried to balance the 
severity of the corrective action with the hope that these members will reflect 
on the reasons for the warnings or ban, and when they next engage with the 
community, how they can more closely follow the spirit and letter of the code 
of conduct.

Making this community a place where people feel included, safe, and welcome is 
exactly why the Steering Council has taken the actions it has taken.  If you 
are still feeling scared, I urge you to reach out to the Steering Council to 
express your concerns and feelings.

Cheers,
-Barry

> On Jul 22, 2020, at 12:40, Ivan Levkivskyi  wrote:
> 
> Hi,
> 
> I don't remember participating in any of the recent discussions on the 
> mentioned lists. Why is this sent to me? Can you mention any particular posts?
> The scary atmosphere here becomes unbearable. I wasn't very active lately 
> anyway, and I think I will stop contributing indefinitely.
> 
> Best regards,
> Ivan
> 
> 
> On Wed, 22 Jul 2020 at 20:30, Python Steering Council 
>  wrote:
> The following message was sent to a core developer. This message was 
> thoughtfully and respectfully sent by the Steering Council as a serious 
> reminder that the privilege to serve as a core developer comes with the 
> responsibility to act thoughtfully.
> 
> ---
> 
> Based on Code of Conduct violations in your recent mailing list posts, and 
> under the recommendation of the Code of Conduct Working Group, the Python 
> Steering Council has voted to issue a three-month corrective action to you 
> for Core Python development.
> This corrective action bans you from all Core Development privileges 
> including commit rights, issue tracker privileges, and participation in all 
> core development communication spaces including mailing lists, Discourse, and 
> Zulip channels. This corrective action will be in effect for three months. At 
> the end of the three month period, these privileges will be automatically 
> reinstated.
> 
> The Python Code of Conduct workgroup reviewed the conduct reports and 
> recommended that corrective action was necessary for the violations. The 
> Python Steering Council finds these violations to be serious breaches of 
> civility and expected core development conduct.
> 
> Please consider this corrective action as a serious reminder that Python core 
> development is a privilege. This privilege to serve as a core developer comes 
> with the responsibility to act thoughtfully and reflect on how hostile 
> communications are harmful to other members of the community. We trust that 
> you will respect the temporary loss of privileges and the seriousness of this 
> action.
> 
> Respectfully,
> Python Steering Council
> ___
> 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/2HC5XPURMQL6VRCXPMLQUL7OXBGU6OMS/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> ___
> 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/CLS5E634FCMB6W5H5JBLHZNSFRKKZGJG/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
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/TQMPBGIHRHUVN7U4G7QX2ZK45XMHHYOI/
Code of Conduct: https://www.python.org/psf/codeofconduct/