[python-committers] commit privileges for INADA Naoki

[Yury Selivanov]

Thanks, Victor!

On Mon, Sep 26, 2016 at 5:27 PM, Victor Stinner
<victor.stinner at 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 at 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 at 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 at gmail.com> wrote:
>>>> On 26 September 2016 at 03:52, Raymond Hettinger
>>>> <raymond.hettinger at gmail.com> wrote:
>>>>>
>>>>>> On Sep 25, 2016, at 8:38 AM, Yury Selivanov <yselivanov.ml at 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 at gmail.com   |   Brisbane, Australia
>>>> _______________________________________________
>>>> python-committers mailing list
>>>> python-committers at 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 at 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 at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/