Re: [python-committers] cherry picking, miss islington, and generated files

[Nick Coghlan]

On 5 February 2018 at 14:47, Mariatta Wijaya  wrote:
>> We already have Travis checking 'make regen-all' and 'make clinic'
>> (assuming it's working correctly).

Ah, I didn't think that idea was a new one :)

> The CI in https://github.com/python/cpython/pull/5498 were all passing, but
> I think we expected it to fail? In the end Barry regenerated the files
> manually.

Heh, I think I have a plausible theory as to what happened:

The 3.7 and 3.8 compilers are currently still identical, and this was
the first post-branch change to importlib (as far as I know), so:

1. The patch applied cleanly (because the previously frozen versions
were the same)
2. The regen check passed (because the regenerated version was the same)

And this is likely to continue to be the case until we either make a
change to importlib or the compiler for 3.8 that we don't backport to
3.7.

Whereas the cherry picking just outright failed on 3.6 because the
current state of the frozen importlib on that branch is different.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@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/

[python-committers] Auto-merge the backport PR with one core dev approval and all passing CI

[Mariatta Wijaya]

Hi,

I will have some time in the next couple weeks to work on miss-islington.
I'm thinking to work on this issue:
https://github.com/python/miss-islington/issues/44

The idea is to have miss-islington automatically merge the backport PR,
after all CI passed and after a core dev approved the PR. I think this will
save us a lot of button clicks and time.

Just wanted to check if everyone is pretty much +1 on this, before I start
writing the code.

Some notes and implicationss:

- The expectation is that the commit message has already been cleaned up on
the master branch
- It already knows how to replace the # to GH- in the commit message
- miss-islington will need write access to CPython
- git log it will show miss-islington (bot) as the committer
- If you still want to do the merge yourself, then just don't approve
miss-islington's PR.

What does everyone here think about all that?

Thanks.

Mariatta Wijaya
___
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/

Re: [python-committers] cherry picking, miss islington, and generated files

[Barry Warsaw]

On Feb 5, 2018, at 09:09, Nick Coghlan  wrote:
> 
> Heh, I think I have a plausible theory as to what happened:
> 
> The 3.7 and 3.8 compilers are currently still identical, and this was
> the first post-branch change to importlib (as far as I know), so:
> 
> 1. The patch applied cleanly (because the previously frozen versions
> were the same)
> 2. The regen check passed (because the regenerated version was the same)

Agreed.  I just wasn’t *positive* I could trust a clean merge and passing 
tests.  Maybe we can though.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/

Re: [python-committers] Auto-merge the backport PR with one core dev approval and all passing CI

[Senthil Kumaran]

Great idea. Definitely, +1.

On Mon, Feb 5, 2018 at 6:07 AM, Mariatta Wijaya 
wrote:

> Hi,
>
> I will have some time in the next couple weeks to work on miss-islington.
> I'm thinking to work on this issue: https://github.com/
> python/miss-islington/issues/44
>
> The idea is to have miss-islington automatically merge the backport PR,
> after all CI passed and after a core dev approved the PR. I think this will
> save us a lot of button clicks and time.
>
> Just wanted to check if everyone is pretty much +1 on this, before I start
> writing the code.
>
> Some notes and implicationss:
>
> - The expectation is that the commit message has already been cleaned up
> on the master branch
> - It already knows how to replace the # to GH- in the commit message
> - miss-islington will need write access to CPython
> - git log it will show miss-islington (bot) as the committer
> - If you still want to do the merge yourself, then just don't approve
> miss-islington's PR.
>
> What does everyone here think about all that?
>
> Thanks.
>
> Mariatta Wijaya
>
> ___
> 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/

Re: [python-committers] Auto-merge the backport PR with one core dev approval and all passing CI

[Senthil Kumaran]

I like to seek one clarification.

I know git has author as well as committer. I am assuming that even if
miss-islington backports the PR, the author'ship of the patch is still
preserved.

Is that correct?

Thank you,
Senthil



On Mon, Feb 5, 2018 at 6:18 AM, Senthil Kumaran  wrote:

> Great idea. Definitely, +1.
>
> On Mon, Feb 5, 2018 at 6:07 AM, Mariatta Wijaya  > wrote:
>
>> Hi,
>>
>> I will have some time in the next couple weeks to work on miss-islington.
>> I'm thinking to work on this issue: https://github.com/pyth
>> on/miss-islington/issues/44
>>
>> The idea is to have miss-islington automatically merge the backport PR,
>> after all CI passed and after a core dev approved the PR. I think this will
>> save us a lot of button clicks and time.
>>
>> Just wanted to check if everyone is pretty much +1 on this, before I
>> start writing the code.
>>
>> Some notes and implicationss:
>>
>> - The expectation is that the commit message has already been cleaned up
>> on the master branch
>> - It already knows how to replace the # to GH- in the commit message
>> - miss-islington will need write access to CPython
>> - git log it will show miss-islington (bot) as the committer
>> - If you still want to do the merge yourself, then just don't approve
>> miss-islington's PR.
>>
>> What does everyone here think about all that?
>>
>> Thanks.
>>
>> Mariatta Wijaya
>>
>> ___
>> 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/

Re: [python-committers] Auto-merge the backport PR with one core dev approval and all passing CI

[Mariatta Wijaya]

On Mon, Feb 5, 2018 at 9:28 AM, Senthil Kumaran  wrote:

> I like to seek one clarification.
>
> I know git has author as well as committer. I am assuming that even if
> miss-islington backports the PR, the author'ship of the patch is still
> preserved.
>
> Is that correct?
>
>
>
Thanks, Senthil.
Currently, the original PR author on master will be credited as a co-author
on backport PRs.
See this example [1] where it says "2 people authored (miss-islington and
csabella) and ncoghlan committed"
If this idea got implemented, I believe it will say "2 people authored
(miss-islington and csabella) and miss-islington committed"

[1]
https://github.com/python/cpython/commit/fea0a12f6bee4a36b2c9533003e33a12c58d2d91
___
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/

Re: [python-committers] Auto-merge the backport PR with one core dev approval and all passing CI

[Nick Coghlan]

On 6 February 2018 at 00:07, Mariatta Wijaya  wrote:
> Some notes and implicationss:
>
> - The expectation is that the commit message has already been cleaned up on
> the master branch
> - It already knows how to replace the # to GH- in the commit message
> - miss-islington will need write access to CPython
> - git log it will show miss-islington (bot) as the committer
> - If you still want to do the merge yourself, then just don't approve
> miss-islington's PR.
>
> What does everyone here think about all that?

+1 from me, as being able to do the backport PR reviews as soon as
Miss Islington creates them means I'll still have the original review
fresh in my mind. (I know I can theoretically do that now, but I
currently tend not to look at the details of the backport PRs until
the CI run is finished)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@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/

Re: [python-committers] cherry picking, miss islington, and generated files

[Mariatta Wijaya]

Maybe we should just do a diff if https://github.com/python/
cpython/pull/5498 and https://github.com/python/cpython/pull/5503
 are identical..

Mariatta Wijaya
___
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/

Re: [python-committers] Auto-merge the backport PR with one core dev approval and all passing CI

[Terry Reedy]

On 2/5/2018 9:34 AM, Nick Coghlan wrote:

On 6 February 2018 at 00:07, Mariatta Wijaya  wrote:

Some notes and implicationss:

- The expectation is that the commit message has already been cleaned up on
the master branch


and that Miss Islington has correctly copied the title and commit message.


- It already knows how to replace the # to GH- in the commit message
- miss-islington will need write access to CPython
- git log it will show miss-islington (bot) as the committer


I believe that this is already true unless there was a merge conflict.


- If you still want to do the merge yourself, then just don't approve
miss-islington's PR.


If I have to use cherry-picker because there is a merge conflict and I 
use cherry-picker --continue after resolving, then I am the author and I 
cannot approve my own PR.  The auto generated title has no relation to 
the title of the original merge, and the commit message is replaced by 
the reminder.  Finding the original commit message to paste in is not easy.



What does everyone here think about all that?


+1


+1 from me, as being able to do the backport PR reviews as soon as
Miss Islington creates them means I'll still have the original review
fresh in my mind.


I have just started doing this, and approving when I am allowed.  I like 
it better than waiting, (or not reviewing).


Terry
___
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/