Simplify developer log

[brettcannon]

Instead of acting like a ledger, make it a list of active and emeritus members. Active members can be listed by the year they got commit privileges while emeritus is alphabetical and lists years active.

E.g.

Active core developers

• 2018
  1. Pablo
• 2003
  1. Brett Cannon
• 1989
  1. Guido van Rossum
• Unknown
  1. Ethan Furman

Emeritus core developers

1. Paul F. Dubois (1998 - 2005)

[Mariatta]

Great idea! I suggest "core developer" instead of "committer".

[Stewori]

This proposal seems to wipe out a lot of information currently contained in the developer log. This is usually information about who recommended the person, but can also be scope information like "for work on the xy module", "for documentation work". Most relevantly it can indicate the person is working on an alternative PSF-owned Python implementation, e.g. "compatibility work for PyPy".

How would this information be preserved?

[Mariatta]

So I realize I don't even know what is considered as "alternative PSF-owned Python implementation". Is there such list somewhere?

[Stewori]

I don't know of an official list, but I think the PSFshould know what software is under their license. E.g. looking at Jython's license, the first paragraph reads

1. This LICENSE AGREEMENT is between the Python Software Foundation
("PSF"), and the Individual or Organization ("Licensee") accessing and
otherwise using this software ("Jython") in source or binary form and
its associated documentation.

If the license agreement is made between users and the PSF that indicates kind of ownership, no? (IANAL) It's also PSF for which the contributor agreement is signed.
In this sense, there is a list in the wikipedia but that's certainly not official.
Apparently that list does not contain PyPy and IronPython, so things might not be that easy. I always assumed they had the same license model as Jython, given that committers were usually included into dev log in the same fashion. However that's a question someone at the PSF or from PyPy or IronPython is better suited to answer.

[berkerpeksag]

I agree with @Stewori.

Looking at PR #404, I think we are losing a lot of information and I don't think the new format is entirely accurate (because the section is now renamed to "Active core developers") For example, see "2014" section at https://github.com/python/devguide/pull/404/files#diff-fe3fd1dac75eba5fb6edcd98b012b444R55 Four of the listed names are not CPython core developers and one of them was added as a PEP editor (i.e. not a CPython or Jython core dev)

[Mariatta]

I think in PR #404, the active core developers should only include CPython core developers and not core developers of alternate implementation.

I still don't understand the historical reason why we were sharing the commit right to alternate Python implementation in the same comimtters.txt file, or even within CPython developer guide.

IronPython is not even under Python infrastructure anymore. It has its own repo: https://github.com/IronLanguages/ironpython2

PyPy maintains their own list of contributors https://pypy.org/people.html and their own repo: https://bitbucket.org/pypy/pypy/ (not under The PSF)

So I think it's good time for us to clean up this log and only maintain info about CPython core development going forward.

[berkerpeksag]

I think Jython is still using our old hg.python.org infrastructure. The source code of their issue tracker is also stored at hg.python.org.

PyPy and IronPython developers were given commit rights to improve compatibility between CPython and PyPy/IronPython (e.g. working on stdlib and test suite)

[terryjreedy]

On 8/2/2018 7:39 AM, Stefan Richthofer wrote: I don't know of an official list, but I think the PSFshould know what software is under their license. E.g. looking at Jython's license, the first paragraph reads |1. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and the Individual or Organization ("Licensee") accessing and otherwise using this software ("Jython") in source or binary form and its associated documentation. | If the license agreement is made between users and the PSF that indicates kind of ownership, no? (IANAL) It's also PSF for which the contributor agreement is signed. In this sense, there is a list in the wikipedia <https://en.wikipedia.org/wiki/Category:Software_using_the_PSF_license> but that's certainly not official. Apparently that list does not contain PyPy and IronPython, so things might not be that easy. I always assumed they had the same license model as Jython, given that committers were usually included into dev log in the same fashion. However that's a question someone at the PSF or from PyPy or IronPython is better suited to answer.

The list does include ABC (Yet Another BitTorrent Client), which is *not* a PSF project. Its Wikipedia page https://en.wikipedia.org/wiki/ABC_(Yet_Another_BitTorrent_Client) leads to its SourceForge page https://sourceforge.net/projects/pingpong-abc/ which leads to https://sourceforge.net/directory/os:windows/license:psfl/ which claims 259 packages with Python Software Foundation License that run on Windows. It appears that many non-PSF projects just checked off a box to mean PSFL-like.

[brettcannon]

We can't control who chooses to use the PSF license, so attempting to list all of them and their contributors is a losing battle that we can never win (and if the PSF cares about that then that is up to them to do, not the core devs).

I also agree that we shouldn't list folks in the devguide who work on other popular interpreter implementations. I would be happy to link to their own list, but keeping this stuff all updated just for folks able to commit to CPython is hard enough.

As for why I want to drop the committer log as currently structured, that's because I'm the one that has to enter it every time and no one has told me they actually read it. 😄 All of those details are also captured in the python-committers mailing list so it isn't like they don't exist somewhere. And we also don't police people if they get commit privileges as to whether they only stick to what they were given commit rights for; we just trust them to do that. So no one to my knowledge has ever said to someone, "hey, the committer log says you can only work on X but you just touched Y!" IOW I'm asking people to justify why I have to update that log like I do, otherwise it's just busy-work for me.

[brettcannon]

I just re-read the commit log and I think there's a misunderstanding about us listing contributors from other implementations. Several contributors to other implementations were given commit privileges specifically for contributing to the stdlib to make it work with other implementations more easily. They are core devs as much as anyone else as they have the same rights and responsibilities.

This was also back in 2014 when our policies for core developers was different, so I don't know if we would have handled things the same way today, but I also don't think we are about to strip anyone's rights either.

[Stewori]

Brett, thank you for this clarification. That makes sense now. I still think we should keep the additional information like Marc Andre pointed out on the mailing list, it's part of our history and I actually found it an interesting read. If that's too costly to maintain, it's a different thing of course.

[jeff5]

@brettcannon : I was a bit surprised to find the Jython developers in the list here, since this is so clearly the CPython devguide.

I question that these non-CPython names are (all) in the list so that other implementations can make commits to the stdlib. Some are so identified, it's true, but the PSF actually provides Jython's infrastructure, owns our domain name and so on (for which much thanks, BTW), and, main point, supports the Mercurial repositories the project moved to when adopted. This last is done in a way that gives me actual access (so I'm told) to all the repositories, which is significant trust.

The PSF needs a list of who has this trust, and some metadata about when it was granted and with what "gentleman's agreement" concerning repositories in one's competence. (At least, I would say this is a necessary safeguard.) I'd expected it to be in private somewhere, but noticing it was here, and I was mssing, I got myself added at the chronological position in the list where I'd been given the access. Needless to say, It should be kept wherever it's easiest to use/maintain.

[berkerpeksag]

IOW I'm asking people to justify why I have to update that log like I do, otherwise it's just busy-work for me.

You can count me as a volunteer :) I also do find both the developer log and https://devguide.python.org/motivations/#published-entries interesting reads. As someone who doesn't attend PyCon US and EuroPython, it helps me to realize that I don't just communicate with bunch of usernames.