commit privileges for INADA Naoki
Hi,
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. He also participated in many asyncio related discussions/PRs, on python-ideas and bug tracker.
He's quite interested in becoming a core developer. I can volunteer to help/mentor INADA until he's comfortable with our processes.
Thanks, Yury
On 26 September 2016 at 01:38, Yury Selivanov yselivanov.ml@gmail.com wrote:
Hi,
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. He also participated in many asyncio related discussions/PRs, on python-ideas and bug tracker.
+1 from me. I've always found him receptive to feedback, and he's illustrated he definitely has the patience needed for the role ;)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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.
Raymond
+1
On Sun, Sep 25, 2016, 20: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.
Raymond
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/
-- Thanks, Andrew Svetlov
On Sun, Sep 25, 2016 at 8:52 PM, 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.
I agree with Raymond on this. I don't see much activity from INADA Naoki on bugs.python.org and I think it's too early for a promotion.
--Berker
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
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)
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/
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/
Thanks, Victor!
On Mon, Sep 26, 2016 at 5:27 PM, Victor Stinner victor.stinner@gmail.com wrote:
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/
I wanted to propose the same thing, but I deferred this item of my TODO after the crazy 3.6 beta 1 :-) So a big +1 for Naoki!
Yury: would you be his mentor? IMHO it is very helpful to have a dedicated mentor for the first weeks.
By the way, I noticed that he seems to follow python-dev according to his well informed blog post (in japenese ;-)): http://methane.hatenablog.jp/entry/2016-09-12/Python3.6b1
Victor
Le 25 sept. 2016 5:38 PM, "Yury Selivanov" yselivanov.ml@gmail.com a écrit :
Hi,
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. He also participated in many asyncio related discussions/PRs, on python-ideas and bug tracker.
He's quite interested in becoming a core developer. I can volunteer to help/mentor INADA until he's comfortable with our processes.
Thanks, Yury
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/
participants (7)
-
Andrew Svetlov -
Berker Peksağ -
Guido van Rossum -
Nick Coghlan -
Raymond Hettinger -
Victor Stinner -
Yury Selivanov