https://docs.python.org/devguide/coredev.html gives some steps ;-)
2016-09-26 17:23 GMT+02:00 Yury Selivanov <yselivanov.ml@gmail.com>:
Thank you guys. I'll send a detailed email to INADA, explaining most basic things (and a link to devguide). And sure thing, I'm OK with mentoring.
Who should I ask to issue commit privileges / update bug tracker info for INADA?
Yury
On Mon, Sep 26, 2016 at 6:05 AM, Guido van Rossum <guido@python.org> wrote:
I'm with Nick. Assuming Yuri wants to mentor Inada I'm all for giving him commit privileges!
On Sun, Sep 25, 2016 at 9:00 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 26 September 2016 at 03:52, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Sep 25, 2016, at 8:38 AM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
I want to propose to give commit privileges to INADA Naoki. He's the guy behind compact dict implementation for CPython 3.6, which was a super complex patch.
I would like to see him do some work reviewing other people's patches and to show that he is making good judgments about what should and shouldn't be done. In a way, making a single big patch is one of the least important parts of being a core developer.
This has come up a couple of times, but I think it carries a mistaken assumption that there's only one way to be a core developer, when "core development" covers a whole range of different activities, from general bug fixing, to facilitating acceptance of other people's patches, to assuming maintenance & design responsibility for particular modules and interpreter subsystems.
I know when I nominated Yury himself for commit privileges it wasn't due to his work reviewing other people's patches - it was due to the fact that I trusted him to ask for a second opinion when he needed one in the areas where we'd been working together, and that the requirement for his patches to go through me in order to be merged was becoming inefficient relative to just granting him the ability to check them in himself after I had looked at them.
If Yury feels the same way regarding Inada-san's contributions to asyncio and the interpreter core, and is prepared to support him in managing the additional responsibilities that come along with that, then I don't see a strong reason to veto that. At most I see reason for a directive to be judicious in how the new access is used, but my experience is that new core developers already naturally take some time to become confident in using their own judgement over asking their sponsor's opinion.
Regards, Nick.
P.S. My perspective on this is also influenced by the fact that I gained my own commit privileges back in the CVS days specifically to work on updates to PEP 346 rather than due to my work on the activity of general patch wrangling (which I still generally don't do outside my particular areas of interest, and even then, hitting a bug or API limitation myself is often the main motivator for applying someone else's patch)
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
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/