Re: [python-committers] Let's give commit privileges to Nathaniel J. Smith

2018-01-25 Thread M.-A. Lemburg 
+1

On 25.01.2018 01:00, Victor Stinner wrote:
> +1
> 
> Impressive list of contributions!
> 
> Victor
> 
> 2018-01-25 0:23 GMT+01:00 Yury Selivanov :
>> Hi,
>>
>> I want to propose granting commit privileges to Nathaniel J. Smith.
>> He's interested in the idea of becoming a core developer, and given
>> the quality of his contributionsI think he won't need any extensive
>> mentoring (although I'll be happy to assist Nathaniel in the
>> beginning).
>>
>> Nathaniel has been a prolific PEP author:
>>
>> * Single-authored: PEP 465 Matrix Multiplication (accepted), PEP 521,
>> PEP 533, PEP 568;
>>
>> * Co-authored: PEP 513 (active), PEP 516, PEP 517 (accepted), PEP 518
>> (accepted), PEP 522.
>>
>> * Many PEPs mention his name in acknowledgements.
>>
>> He also has a few sufficiently complex patches committed, some of
>> which touch complex areas like ceval loop and signals handling:
>>
>> * bpo-32591: Add native coroutine origin tracking
>> * bpo-30579: Allow TracebackType creation and tb_next mutation from Python
>> * bpo-30050: Allow disabling full buffer warnings in signal.set_wakeup_fd
>> * bpo-30039: Don't run signal handlers while resuming a yield from stack
>> * bpo-30038: fix race condition in signal delivery + wakeup fd
>> * etc
>>
>> He's been very active on python-dev, python-ideas, bugs.python.org and
>> github. Here's an example where Nathaniel's research helped us to make
>> a right decision to fix a broken socket object API:
>> https://bugs.python.org/msg308450.
>>
>> He helped me quite a bit with the design of PEP 550 and PEP 567, and
>> he's doing some interesting work in the async/await area.
>>
>> So... let's make it happen? :)
>>
>> Yury
>> ___
>> python-committers mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 25 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
python-committers mailing list
[email protected]
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

2018-01-25 Thread INADA Naoki 
+1

-- 
INADA Naoki  
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Mentoring and promoting contributors (was: Let's give commit privileges to Nathaniel J. Smith)

2018-01-25 Thread Victor Stinner 
Hi,

2018-01-25 0:29 GMT+01:00 Eric V. Smith :
> +1. I actually thought [Nathaniel Smith] was a committer already.

By the way, if you notice an active contributor is good candidate to
become a core dev in the long term, you may start the process that I
described here:
https://github.com/vstinner/misc/blob/master/cpython/pep-core_dev_process.rst

My proposed process is made of small steps to build a trust
relationship and to train contributors until they produce
"commit-ready change".

For you, the main requirement is time, be available to review changes
and answers to questions by email :-)

Last weeks, I looked at contributors who got the most commits merged
into master in the last 6 months. That's how I selected Cheryl
Sabella, Sanyam Khurana and Pablo Galindo Salgado.

I also asked two contributors if they would like to become core, but
they declined my offer.


I added a new section in my process document: § "Becoming A Core
Developer Is Not a Goal". I'm not sure that it's the best title ever.

"""
CPython isn't the easiest place to start. The development process is
rather enterprisy with long release cycles (release every 18 months)
and rigid backwards compatibility policy. CPython also support many
different platforms and CPU architectures.

Are you sure that CPython itself is the best project for you?
Depending on your interests and skills, you may enjoy better to
contribute to another Python project with lower backward compatibility
constraints and a faster release cycle.

Being a CPython core developer involves responsibilities and usually
requires a lot of time. Long-term commitment is also a major
expectation, even if it's not a strict requirement. Becoming a core
developer should not be seen as a recognition of a contributor work,
but more as a constraint :-) Merging a change implies becoming
responsible regressions, backward compatibility, security, etc. of
this code.

It is perfectly fine to contribute to CPython without being a core
developer. In most cases, not being able to merge your own work is not
a blocker issue.
"""

I'm not sure about this sentence: "Becoming a core developer should
not be seen as a recognition of a contributor work, but more as a
constraint :-)". My intent is to discourage people who "want to become
a core dev" for the bad reasons (to become famous? I don't know
exactly) without understanding the expected responsibilities.

Victor
___
python-committers mailing list
[email protected]
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

2018-01-25 Thread Paul Moore 
+1 from me also. He's been involved in a lot of distutils-sig stuff as
well, and his contributions have always been well thought out and
useful.
Paul

On 24 January 2018 at 23:23, Yury Selivanov  wrote:
> Hi,
>
> I want to propose granting commit privileges to Nathaniel J. Smith.
> He's interested in the idea of becoming a core developer, and given
> the quality of his contributionsI think he won't need any extensive
> mentoring (although I'll be happy to assist Nathaniel in the
> beginning).
>
> Nathaniel has been a prolific PEP author:
>
> * Single-authored: PEP 465 Matrix Multiplication (accepted), PEP 521,
> PEP 533, PEP 568;
>
> * Co-authored: PEP 513 (active), PEP 516, PEP 517 (accepted), PEP 518
> (accepted), PEP 522.
>
> * Many PEPs mention his name in acknowledgements.
>
> He also has a few sufficiently complex patches committed, some of
> which touch complex areas like ceval loop and signals handling:
>
> * bpo-32591: Add native coroutine origin tracking
> * bpo-30579: Allow TracebackType creation and tb_next mutation from Python
> * bpo-30050: Allow disabling full buffer warnings in signal.set_wakeup_fd
> * bpo-30039: Don't run signal handlers while resuming a yield from stack
> * bpo-30038: fix race condition in signal delivery + wakeup fd
> * etc
>
> He's been very active on python-dev, python-ideas, bugs.python.org and
> github. Here's an example where Nathaniel's research helped us to make
> a right decision to fix a broken socket object API:
> https://bugs.python.org/msg308450.
>
> He helped me quite a bit with the design of PEP 550 and PEP 567, and
> he's doing some interesting work in the async/await area.
>
> So... let's make it happen? :)
>
> Yury
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] core developer status

2018-01-25 Thread Xavier de Gaye 
I have decided for personal reasons to stop contributing to CPython as a core developer, that does not mean I will stop contributing to CPython. So please remove me from the list of core developers 
and revoke all my access rights. Thank you.


Xavier
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Requirements to get the "bug triage" permission?

2018-01-25 Thread Jesus Cea 
On 06/12/17 23:17, Victor Stinner wrote:
> My problem is that we don't have a long list of "awards" in Python:
> the triage bit and the commit bit...
> 
> I had some ideas to create badges, but before I come with something
> concrete, I'm trying to build something with what we already have ;-)

I have been a few weeks thinking about OpenBadges and CPython
development. Not for gamification but for recognition.

In the mood to consider this?

-- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
[email protected] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:[email protected]  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz



signature.asc
Description: OpenPGP digital signature
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Requirements to get the "bug triage" permission?

2018-01-25 Thread Victor Stinner 
2018-01-25 15:18 GMT+01:00 Jesus Cea :
> On 06/12/17 23:17, Victor Stinner wrote:
>> My problem is that we don't have a long list of "awards" in Python:
>> the triage bit and the commit bit...
>>
>> I had some ideas to create badges, but before I come with something
>> concrete, I'm trying to build something with what we already have ;-)
>
> I have been a few weeks thinking about OpenBadges and CPython
> development. Not for gamification but for recognition.
>
> In the mood to consider this?

Hi Jesus,

Which kind of badges do you suggest?

Victor
___
python-committers mailing list
[email protected]
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

2018-01-25 Thread Ezio Melotti 
+1

On Thu, Jan 25, 2018 at 12:23 AM, Yury Selivanov
 wrote:
> Hi,
>
> I want to propose granting commit privileges to Nathaniel J. Smith.
> He's interested in the idea of becoming a core developer, and given
> the quality of his contributionsI think he won't need any extensive
> mentoring (although I'll be happy to assist Nathaniel in the
> beginning).
>
> Nathaniel has been a prolific PEP author:
>
> * Single-authored: PEP 465 Matrix Multiplication (accepted), PEP 521,
> PEP 533, PEP 568;
>
> * Co-authored: PEP 513 (active), PEP 516, PEP 517 (accepted), PEP 518
> (accepted), PEP 522.
>
> * Many PEPs mention his name in acknowledgements.
>
> He also has a few sufficiently complex patches committed, some of
> which touch complex areas like ceval loop and signals handling:
>
> * bpo-32591: Add native coroutine origin tracking
> * bpo-30579: Allow TracebackType creation and tb_next mutation from Python
> * bpo-30050: Allow disabling full buffer warnings in signal.set_wakeup_fd
> * bpo-30039: Don't run signal handlers while resuming a yield from stack
> * bpo-30038: fix race condition in signal delivery + wakeup fd
> * etc
>
> He's been very active on python-dev, python-ideas, bugs.python.org and
> github. Here's an example where Nathaniel's research helped us to make
> a right decision to fix a broken socket object API:
> https://bugs.python.org/msg308450.
>
> He helped me quite a bit with the design of PEP 550 and PEP 567, and
> he's doing some interesting work in the async/await area.
>
> So... let's make it happen? :)
>
> Yury
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
[email protected]
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

2018-01-25 Thread Yury Selivanov 
Alright, it's decided!  I now envy Nathaniel a bit, so many people +1-ed!

I've added Nathaniel to devguide/developers.rst, and I believe Victor
has already elevated his permissions on the bug tracker.

Can someone with admin permissions on github.com/python invite
Nathaniel to the Core Developers team?

Yury

On Thu, Jan 25, 2018 at 10:33 AM, Ezio Melotti  wrote:
> +1
>
> On Thu, Jan 25, 2018 at 12:23 AM, Yury Selivanov
>  wrote:
>> Hi,
>>
>> I want to propose granting commit privileges to Nathaniel J. Smith.
>> He's interested in the idea of becoming a core developer, and given
>> the quality of his contributionsI think he won't need any extensive
>> mentoring (although I'll be happy to assist Nathaniel in the
>> beginning).
>>
>> Nathaniel has been a prolific PEP author:
>>
>> * Single-authored: PEP 465 Matrix Multiplication (accepted), PEP 521,
>> PEP 533, PEP 568;
>>
>> * Co-authored: PEP 513 (active), PEP 516, PEP 517 (accepted), PEP 518
>> (accepted), PEP 522.
>>
>> * Many PEPs mention his name in acknowledgements.
>>
>> He also has a few sufficiently complex patches committed, some of
>> which touch complex areas like ceval loop and signals handling:
>>
>> * bpo-32591: Add native coroutine origin tracking
>> * bpo-30579: Allow TracebackType creation and tb_next mutation from Python
>> * bpo-30050: Allow disabling full buffer warnings in signal.set_wakeup_fd
>> * bpo-30039: Don't run signal handlers while resuming a yield from stack
>> * bpo-30038: fix race condition in signal delivery + wakeup fd
>> * etc
>>
>> He's been very active on python-dev, python-ideas, bugs.python.org and
>> github. Here's an example where Nathaniel's research helped us to make
>> a right decision to fix a broken socket object API:
>> https://bugs.python.org/msg308450.
>>
>> He helped me quite a bit with the design of PEP 550 and PEP 567, and
>> he's doing some interesting work in the async/await area.
>>
>> So... let's make it happen? :)
>>
>> Yury
>> ___
>> python-committers mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
[email protected]
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

2018-01-25 Thread Brett Cannon 
Done, making Nathaniel the 90th member of the current core team! He also
needs to send a subscription request for python-committers.

On Thu, 25 Jan 2018 at 09:24 Yury Selivanov  wrote:

> Alright, it's decided!  I now envy Nathaniel a bit, so many people +1-ed!
>
> I've added Nathaniel to devguide/developers.rst, and I believe Victor
> has already elevated his permissions on the bug tracker.
>
> Can someone with admin permissions on github.com/python invite
> Nathaniel to the Core Developers team?
>
> Yury
>
> On Thu, Jan 25, 2018 at 10:33 AM, Ezio Melotti 
> wrote:
> > +1
> >
> > On Thu, Jan 25, 2018 at 12:23 AM, Yury Selivanov
> >  wrote:
> >> Hi,
> >>
> >> I want to propose granting commit privileges to Nathaniel J. Smith.
> >> He's interested in the idea of becoming a core developer, and given
> >> the quality of his contributionsI think he won't need any extensive
> >> mentoring (although I'll be happy to assist Nathaniel in the
> >> beginning).
> >>
> >> Nathaniel has been a prolific PEP author:
> >>
> >> * Single-authored: PEP 465 Matrix Multiplication (accepted), PEP 521,
> >> PEP 533, PEP 568;
> >>
> >> * Co-authored: PEP 513 (active), PEP 516, PEP 517 (accepted), PEP 518
> >> (accepted), PEP 522.
> >>
> >> * Many PEPs mention his name in acknowledgements.
> >>
> >> He also has a few sufficiently complex patches committed, some of
> >> which touch complex areas like ceval loop and signals handling:
> >>
> >> * bpo-32591: Add native coroutine origin tracking
> >> * bpo-30579: Allow TracebackType creation and tb_next mutation from
> Python
> >> * bpo-30050: Allow disabling full buffer warnings in
> signal.set_wakeup_fd
> >> * bpo-30039: Don't run signal handlers while resuming a yield from stack
> >> * bpo-30038: fix race condition in signal delivery + wakeup fd
> >> * etc
> >>
> >> He's been very active on python-dev, python-ideas, bugs.python.org and
> >> github. Here's an example where Nathaniel's research helped us to make
> >> a right decision to fix a broken socket object API:
> >> https://bugs.python.org/msg308450.
> >>
> >> He helped me quite a bit with the design of PEP 550 and PEP 567, and
> >> he's doing some interesting work in the async/await area.
> >>
> >> So... let's make it happen? :)
> >>
> >> Yury
> >> ___
> >> python-committers mailing list
> >> [email protected]
> >> https://mail.python.org/mailman/listinfo/python-committers
> >> Code of Conduct: https://www.python.org/psf/codeofconduct/
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] core developer status

2018-01-25 Thread Brett Cannon 
I have removed your access on GitHub and unsubscribed you from
python-committers. Sorry to see you go, Xavier, but look forward to
continuing to work with you on PRs!

On Thu, 25 Jan 2018 at 04:29 Xavier de Gaye  wrote:

> I have decided for personal reasons to stop contributing to CPython as a
> core developer, that does not mean I will stop contributing to CPython. So
> please remove me from the list of core developers
> and revoke all my access rights. Thank you.
>
> Xavier
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] core developer status

2018-01-25 Thread Zachary Ware 
On Thu, Jan 25, 2018 at 11:59 AM, Brett Cannon  wrote:
> I have removed your access on GitHub and unsubscribed you from
> python-committers.

Also flipped the 'is_committer' bit to off on the bug tracker.

> Sorry to see you go, Xavier, but look forward to
> continuing to work with you on PRs!

Completely agreed!

-- 
Zach
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] AppVeyor is now required to pass on PRs

2018-01-25 Thread Brett Cannon 
On Wed, 24 Jan 2018 at 10:12 Victor Stinner 
wrote:

> Hi,
>
> AppVeyor usually takes between 30 min and 1 hour to check a PR,
> whereas Travis CI takes between 10 and 20 minutes (in average,
> ignoring rare cases when it's broken). AppVeyor queue is regulary
> busy.
>
> Sometimes, I know that my PR is right, because the fix is obvious.
> Sometimes, the PR has no impact on Windows. In these cases, the slow
> AppVeyor CI can be annoying since it prevents me to merge a PR.
>
> What do you think of making AppVeyor optional again? Careful core
> developers should wait for AppVeyor, except if they know that Windows
> doesn't matter for a specific PR.
>

No one has spoken up so I guess everyone else is okay with the delay ATM.
My worry with flipping it off and trusting ourselves this close to the beta
is the last time I did that people didn't wait and we landed breaking
changes. So unless other people speak up that the delay is a hindrance I'm
inclined to leave it until we at least get past the beta.

-Brett


>
> Victor
>
> 2018-01-10 21:45 GMT+01:00 Brett Cannon :
> > I just switched it on to help make sure we don't break on Windows just
> > before hitting beta. If it turns out AppVeyor isn't stable enough I will
> > switch it back off.
> >
> > ___
> > python-committers mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] AppVeyor is now required to pass on PRs

2018-01-25 Thread Mariatta Wijaya 
I'm fine with the delay. I've been thinking to implement the bot that will
remind us when all the CI has been completed.
So we don't have to wait, and won't forget about it.

Currently miss-islington does this only for the backport PRs made by
miss-islington.
I think it'll be useful to do that on other PRs too.
(yes I'm aware GitLab does this but we are on GitHub)

Mariatta Wijaya
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] AppVeyor is now required to pass on PRs

2018-01-25 Thread Terry Reedy 

On 1/25/2018 1:52 PM, Brett Cannon wrote:



On Wed, 24 Jan 2018 at 10:12 Victor Stinner > wrote:



AppVeyor usually takes between 30 min and 1 hour to check a PR,


Yesterday, AppVeyor surprised me by finishing in about 6 minutes, 
handily beating Travis.  I wonder whether this was a fluke, or if 
something changed somewhere.  Or was it the luck of no backlog.


No one has spoken up so I guess everyone else is okay with the delay 
ATM. My worry with flipping it off and trusting ourselves this close to 
the beta is the last time I did that people didn't wait and we landed 
breaking changes. So unless other people speak up that the delay is a 
hindrance I'm inclined to leave it until we at least get past the beta.


Since I develop and test on Windows, I don't usually need the AppVeyor 
test*, but for patches developed on *nix, it is needed.


* Even then, there was one IDLE test change that interfered with another 
test, only on Windows.


Terry
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] AppVeyor is now required to pass on PRs

2018-01-25 Thread Victor Stinner 
Hi,

The best would be able to have a bot merging a pull request once tests
pass and a core developer asked a merge. I'm not talking about the
current approval using review, but something new, like adding a
special comment like "Merge". Such comment would only merge if it's
written by a core developer.

Each time I approve a backport PR created by miss-ilington with "LGTM,
good bot", I hope secretly that the PR will be merged automatically
once CI tests pass ;-)

Is it possible to write a bot which merges a PR?

Victor

2018-01-25 20:04 GMT+01:00 Mariatta Wijaya :
> I'm fine with the delay. I've been thinking to implement the bot that will
> remind us when all the CI has been completed.
> So we don't have to wait, and won't forget about it.
>
> Currently miss-islington does this only for the backport PRs made by
> miss-islington.
> I think it'll be useful to do that on other PRs too.
> (yes I'm aware GitLab does this but we are on GitHub)
>
> Mariatta Wijaya
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] AppVeyor is now required to pass on PRs

2018-01-25 Thread Mariatta Wijaya 
>
> Is it possible to write a bot which merges a PR?


Yes it is possible, and we sort of discussing the same thing in python-dev
[1] :)

Each time I approve a backport PR created by miss-ilington with "LGTM,
> good bot", I hope secretly that the PR will be merged automatically
> once CI tests pass ;-)


You should have filed a feature request! :D
To make it happen, I'll need miss-islington be promoted and given write
access to CPython.
Currently miss-islington can't merge.

[1] https://mail.python.org/pipermail/python-dev/2018-January/151899.html

Mariatta Wijaya
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] AppVeyor is now required to pass on PRs

2018-01-25 Thread Terry Reedy 

On 1/25/2018 4:31 PM, Victor Stinner wrote:

Hi,

The best would be able to have a bot merging a pull request once tests
pass and a core developer asked a merge. I'm not talking about the
current approval using review, but something new, like adding a
special comment like "Merge". Such comment would only merge if it's
written by a core developer.

Each time I approve a backport PR created by miss-ilington with "LGTM,
good bot", I hope secretly that the PR will be merged automatically
once CI tests pass ;-)


Great idea.  At this point, pressing the button is, for me at least, a 
formality.


tjr
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] trivial tag on GitHub?

2018-01-25 Thread Ethan Furman 

I created a new pull request to add a forgotten news entry, and now it's going 
through all the pre-checks, etc.

I seem to recall we could add a "trivial" tag to an issue to skip those.  Is 
that still true, and if so, how?

--
~Ethan~
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/