[python-committers] CLA bot bug for a particular contributor

[Antoine Pitrou]

Hi,

How can I get the CLA bot to fix its knowledge for a particular contributor?

bugs.python.org user Gareth Rees (https://bugs.python.org/user14554) has
signed the CLA and filled in his GitHub username "gareth-rees".

However, a PR filed by Gareth
(https://github.com/python/cpython/pull/2741) has the "CLA not signed"
label added.  I could fix that particular label myself but am I wrong in
thinking that further PRs would still have the wrong label assigned?

Regards

Antoine.
___
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] "trivial" label replaced with "skip issue"

[Antoine Pitrou]

Le 17/07/2017 à 22:16, Brett Cannon a écrit :
> 
> 
> On Sun, 16 Jul 2017 at 15:22 Victor Stinner  > wrote:
> 
> 2017-07-16 16:10 GMT+02:00 Victor Stinner  >:
> > What is the benefit of converting old Misc/NEWS entries?
> 
> I guess that the benefit is to use a single format for all NEWS
> entries. I understand that it will ease the build of the changelog.
> 
> 
> It's to ease backporting since you will never have Misc/NEWS have a
> merge conflict ever again.

Can I take the opportunity to say thank you again (both you and Larry)
for the "blurb" tool?  It really makes an important difference when
contributing.

Regards

Antoine.
___
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] CLA bot bug for a particular contributor

[Victor Stinner]

I removed the "CLA not signed" and automatically, the label "CLA
signed" appears in 2 seconds ;-) Have a nice day.

Victor

2017-07-18 11:34 GMT+02:00 Antoine Pitrou :
>
> Hi,
>
> How can I get the CLA bot to fix its knowledge for a particular contributor?
>
> bugs.python.org user Gareth Rees (https://bugs.python.org/user14554) has
> signed the CLA and filled in his GitHub username "gareth-rees".
>
> However, a PR filed by Gareth
> (https://github.com/python/cpython/pull/2741) has the "CLA not signed"
> label added.  I could fix that particular label myself but am I wrong in
> thinking that further PRs would still have the wrong label assigned?
>
> Regards
>
> Antoine.
> ___
> 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/

[python-committers] My (positive) feedback on the new CPython workflow

[Victor Stinner]

Hi,

2017-07-18 11:36 GMT+02:00 Antoine Pitrou :
> Can I take the opportunity to say thank you again (both you and Larry)
> for the "blurb" tool?  It really makes an important difference when
> contributing.
>
> Regards
>
> Antoine.

I concur with Antoine, I'm now *very* happy with the new workflow. The
code became better, many things are much simpler for me (especially
the tasks that I don't have to do myself anymore ;-)), my productivity
increases and I see more and more active contributors, much more than
before the move to GitHub and new workflow!


== Introduction ==

Two friends asked me recently how is the new Python workflow going.

Somehow, I decided to not express myself on the topic to avoid dummy
knee-jerk reaction like "it sucks, it was better before, xxx doesn't
work, now I have to xxx, etc."

It took me at least 3 months to be used to the new workflow, while
tools were developed and enhanced, and the workflow was adjusted based
on our early feedback.

So, here is my feedback :-)


== pre-commit CI: less regressions ==

>From a pure technical point of view, IMHO pre-commit CI on Linux
(Travis CI) and Windows (AppVeyor) is a *MAJOR* enhancement. (I don't
count macOS, since it's not mandatory yet.)

For example, before GitHub, it was common to break Windows since too
few core developers were running tests *manually* on Windows.

It's hard to prove my point, so try to trust me: we reduce a lot the
number of regressions introduced by new changesets. Before, every two
weeks, we had to rush to push fixes in urgency (which sometimes leaded
to bad code which required multiple iterations until we find the best
fix).

It was especially annoying when a dev pushed a big change just before
being away for 8-12 hours, which means having to push a fix without
the review of the change author :-(


== More contributors, more contributions, faster reviewed/merged ==

In term of contributions, I looked at statistics yesterday and it
became clear the number of different authors is significantely much
higher, around 25 contributors / month before, now closer to 50:
https://www.openhub.net/p/python/contributors/summary

Well, Git allows to store the original author, so statistics are
simplify higher just because previously the tools failed to identify
the real author.

But I'm watching the bug tracker, pull requests, and Git commits:
there are a lot of *new* contributors, we get more contributions, and
we are *faster* to integrate them.

I also saw again inactive core contributors starting to review again,
or even write new PRs! It's a very good sign of the good health of our
project!

More generally, the whole development seems to be more active, more
productive and more *healthy*.


== Better scale horizontally ==

The new workflow better scales horizontally since we delegated much
more work to the contributor. Previously the core developers were more
the bottleneck.

Tasks delegated to the contributors:

* create the PR itself (can you still remind when we had to download a
patch file and create a commit? ;-)),

* write the commit message (I always hated to do that without any kind
of review...),

* add the NEWS entry (before it was common to explicitly ask to *not*
write it... to avoid conflicts with Misc/NEWS...).

* most contributors create backports (using cherry-pick) themself.
Before, this painful/error-prone task was usually done by a single
developer without any review, without pre-commit tests, etc.

Note: I didn't see any contributor complaining about having to do
these tasks. It seems like it's more the opposite, they are happy to
be more *involved* in the project!


== GitHub ==

I never had to explain how to create an account on GitHub, nor how to
create a PR.

Signing the CLA doesn't seem to be a blocker point neither,
contributors are able to sign it and the bot tracks correctly the CLA
status (thanks Brett for the bot! it's nice to feel safe for legal
issues ;-)).

Maybe we have an excellent documentation. Maybe developers already
know well the GitHub platform.

Even for backports, I didn't have to explain how to cherry-pick a
commit, but it was common that I pointed to the devguide section when
I proposed the author to do the backport himself/herself.

Having explicitly a list of "Approve" and "Requet changes" votes helps
to *quickly* have an overview of the review status.

I'm just not unconfortable with the fact that an approval is kept even
if the PR is modified after the review :-/ I would expect a list a
notice "changed modified after the review" or something like that. At
least, for my own reviews, to remind me to review again.

The [First time contributor] label on PR helps to remind Misc/ACKS:
ask the author to add himself/herself to ACKS.

Compared to Rietveld, GitHub review tool is as "a good" (not much
better, not much worse). Sometimes, I'm lost in reviews: my comments
are hidden, I have to unfold many widgets. But it's not that bad. It
seems like avoiding rebase works around some of

Re: [python-committers] My (positive) feedback on the new CPython workflow

[Serhiy Storchaka]

18.07.17 13:24, Victor Stinner пише:

== More contributors, more contributions, faster reviewed/merged ==

In term of contributions, I looked at statistics yesterday and it
became clear the number of different authors is significantely much
higher, around 25 contributors / month before, now closer to 50:
https://www.openhub.net/p/python/contributors/summary

Well, Git allows to store the original author, so statistics are
simplify higher just because previously the tools failed to identify
the real author.

But I'm watching the bug tracker, pull requests, and Git commits:
there are a lot of *new* contributors, we get more contributions, and
we are *faster* to integrate them.

I also saw again inactive core contributors starting to review again,
or even write new PRs! It's a very good sign of the good health of our
project!

More generally, the whole development seems to be more active, more
productive and more *healthy*.


I have a different impression. Some core developers (like Raymond or 
Martin) stopped committing even if they are active on the bug tracker or 
mailing lists. Others make much less commits than they did before the 
migration.


I rather like the new workflow (except few lost features), but I afraid 
than many core developers are feeling uncomfortable with it.


___
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] My (positive) feedback on the new CPython workflow

[Antoine Pitrou]

Le 18/07/2017 à 13:36, Serhiy Storchaka a écrit :
> 
> I have a different impression. Some core developers (like Raymond or 
> Martin) stopped committing even if they are active on the bug tracker or 
> mailing lists. Others make much less commits than they did before the 
> migration.

Assuming you meant Martin von Löwis, I think Martin stopped contributing
long before we migrated to git (unfortunately, I might add).  I hope
he's doing ok.

Regards

Antoine.
___
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] My (positive) feedback on the new CPython workflow

[Nick Coghlan]

On 18 July 2017 at 21:36, Serhiy Storchaka  wrote:
> I rather like the new workflow (except few lost features), but I afraid than
> many core developers are feeling uncomfortable with it.

Aye, I think for folks already familiar with git and PR-style
workflows through other projects, it's been almost a pure win,
especially as various aspects have become more automated.

However, for folks that *weren't* already familiar with those, it's a
pretty steep learning curve, and one accompanied by a non-trivial
increase in the overall pace of development.

So in addition to thanking the folks working on the migration and the
associated automation, I'd also like to explicitly thank Mariatta,
Terry, Zachary, and everyone else that has contributed to the git
cheatsheet and other workflow documentation updates in the developer's
guide.

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] Unreliable contributor stats

[Antoine Pitrou]

Le 18/07/2017 à 12:24, Victor Stinner a écrit :
> 
> == More contributors, more contributions, faster reviewed/merged ==
> 
> In term of contributions, I looked at statistics yesterday and it
> became clear the number of different authors is significantely much
> higher, around 25 contributors / month before, now closer to 50:
> https://www.openhub.net/p/python/contributors/summary

Beware of how those numbers are calculated.

When we were using hg, patches were typically committed by core
developers, so only core developers appeared as "contributors" in the hg
log.

Now we're using GitHub, commits are made by their contributors
themselves, so the git log now shows their names.

(note the difference is really GitHub PRs vs. applying-patches-by-hand,
not git vs. hg)


Furthermore, based on https://www.openhub.net/p/python/commits/summary,
it seems the latest stats collected by OpenHub date back to 30th May
2017.  They are two months late.

Regards

Antoine.
___
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] My (positive) feedback on the new CPython workflow

[Serhiy Storchaka]

18.07.17 14:40, Antoine Pitrou пише:

Assuming you meant Martin von Löwis, I think Martin stopped contributing
long before we migrated to git (unfortunately, I might add).  I hope
he's doing ok.


I meant Martin Panter. His was the third of most active committers 
recent two years, but didn't commit anything recent months.


___
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] "Invalid symmetric difference expression" on Travis-CI

[Antoine Pitrou]

Hi,

I've just got this weird error on Travis-CI (the build itself is still
marked green, which is great :-D):
https://travis-ci.org/python/cpython/jobs/254906991

"""
$ set -e
  if ! git diff --name-only $TRAVIS_COMMIT_RANGE | grep -qvE
'(\.rst$)|(^Doc)|(^Misc)'
  then
echo "Only docs were updated, stopping build process."
exit
  fi
  ./configure --with-pydebug
  make -j4
  make -j4 regen-all clinic
  changes=`git status --porcelain`
  if ! test -z "$changes"
  then
echo "Generated files not up to date"
echo "$changes"
exit 1
  fi

fatal: Invalid symmetric difference expression
8a8d28501fc8ce25926d168f1c657656c809fd4c...84e0e7a063215809b81e59ab7f59c8bf44492aa8
Only docs were updated, stopping build process.
"""

Regards

Antoine.
___
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] Unreliable contributor stats

[Victor Stinner]

2017-07-18 13:57 GMT+02:00 Antoine Pitrou :
> Beware of how those numbers are calculated.
>
> When we were using hg, patches were typically committed by core
> developers, so only core developers appeared as "contributors" in the hg
> log.

Right, that's why I wrote:

"Well, Git allows to store the original author, so statistics are
simplify higher just because previously the tools failed to identify
the real author."

I asked Mercurial developers if they would like to add a "committer"
field, but this feature was never implemented :-(

Victor
___
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] How do I kill an AppVeyor build?

[Antoine Pitrou]

Hi,

It seems only some select people have the ability to kill or re-launch
AppVeyor builds?

Regards

Antoine.
___
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] How do I kill an AppVeyor build?

[Paul Moore]

You need to log on as the Appveyor account in order to manage builds.
It's possible to link a Github team with an Appveyor admin role to
allow the team to all have the ability to (effectively) log in as the
appveyor account. It's a bit fiddly to set up (and use :-() but it
does work. If whoever currently owns the cpython appveyor account
wants help setting things up, I've done it for pip so I can assist.

Paul

On 18 July 2017 at 17:20, Antoine Pitrou  wrote:
>
> Hi,
>
> It seems only some select people have the ability to kill or re-launch
> AppVeyor builds?
>
> Regards
>
> Antoine.
> ___
> 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] How do I kill an AppVeyor build?

[Brett Cannon]

I set up the account and Zach has access. If you have instructions to point
me at, Paul, I can see if I can set it up.

On Tue, 18 Jul 2017 at 09:26 Paul Moore  wrote:

> You need to log on as the Appveyor account in order to manage builds.
> It's possible to link a Github team with an Appveyor admin role to
> allow the team to all have the ability to (effectively) log in as the
> appveyor account. It's a bit fiddly to set up (and use :-() but it
> does work. If whoever currently owns the cpython appveyor account
> wants help setting things up, I've done it for pip so I can assist.
>
> Paul
>
> On 18 July 2017 at 17:20, Antoine Pitrou  wrote:
> >
> > Hi,
> >
> > It seems only some select people have the ability to kill or re-launch
> > AppVeyor builds?
> >
> > Regards
> >
> > Antoine.
> > ___
> > 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/
>
___
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] How do I kill an AppVeyor build?

[Paul Moore]

I'll get something for you, but it may not be for a couple of days.
Paul

On 18 July 2017 at 18:23, Brett Cannon  wrote:
> I set up the account and Zach has access. If you have instructions to point
> me at, Paul, I can see if I can set it up.
>
>
> On Tue, 18 Jul 2017 at 09:26 Paul Moore  wrote:
>>
>> You need to log on as the Appveyor account in order to manage builds.
>> It's possible to link a Github team with an Appveyor admin role to
>> allow the team to all have the ability to (effectively) log in as the
>> appveyor account. It's a bit fiddly to set up (and use :-() but it
>> does work. If whoever currently owns the cpython appveyor account
>> wants help setting things up, I've done it for pip so I can assist.
>>
>> Paul
>>
>> On 18 July 2017 at 17:20, Antoine Pitrou  wrote:
>> >
>> > Hi,
>> >
>> > It seems only some select people have the ability to kill or re-launch
>> > AppVeyor builds?
>> >
>> > Regards
>> >
>> > Antoine.
>> > ___
>> > 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/
___
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] How do I kill an AppVeyor build?

[Zachary Ware]

On Tue, Jul 18, 2017 at 12:23 PM, Brett Cannon  wrote:
> I set up the account and Zach has access. If you have instructions to point
> me at, Paul, I can see if I can set it up.

Looks like https://ci.appveyor.com/gitHubTeams while logged in as 'python'.

That looks like the right place to make the changes, anyway; I haven't
tried to actually make any :)

-- 
Zach
___
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] How do I kill an AppVeyor build?

[Paul Moore]

That's the one. If you select the github team you want (for PyPA I set
up an "Appveyor Admins" team) and choose the Administrator role. That
may well be all you need to do - I don't recall if you need to do
anything on the github side.

Once you do that, people in the relevant github group, when logging
into Appveyor with github will get a message "Specified user belongs
to multiple accounts" and the "Account" dropdown will contain their
own account and "python". They need to select "python" to get the
option to manage (cancel or restart) builds.

One reason we might want to restrict access is that logging in like
this gives the user full access to the Appveyor account, including (as
far as I can tell) the ability to grant further privileges. It's
possible to create additional roles, but I don't see a "Cancel and
restart builds" privilege.

I think that's all that's needed - give me a shout if I've missed anything.
Paul


On 18 July 2017 at 19:07, Zachary Ware  wrote:
> On Tue, Jul 18, 2017 at 12:23 PM, Brett Cannon  wrote:
>> I set up the account and Zach has access. If you have instructions to point
>> me at, Paul, I can see if I can set it up.
>
> Looks like https://ci.appveyor.com/gitHubTeams while logged in as 'python'.
>
> That looks like the right place to make the changes, anyway; I haven't
> tried to actually make any :)
>
> --
> Zach
> ___
> 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] How do I kill an AppVeyor build?

[Paul Moore]

BTW, the docs for all this are at
https://www.appveyor.com/docs/team-setup/#github-integration although
I found them a bit hard to follow, personally.

Paul

On 18 July 2017 at 19:15, Paul Moore  wrote:
> That's the one. If you select the github team you want (for PyPA I set
> up an "Appveyor Admins" team) and choose the Administrator role. That
> may well be all you need to do - I don't recall if you need to do
> anything on the github side.
>
> Once you do that, people in the relevant github group, when logging
> into Appveyor with github will get a message "Specified user belongs
> to multiple accounts" and the "Account" dropdown will contain their
> own account and "python". They need to select "python" to get the
> option to manage (cancel or restart) builds.
>
> One reason we might want to restrict access is that logging in like
> this gives the user full access to the Appveyor account, including (as
> far as I can tell) the ability to grant further privileges. It's
> possible to create additional roles, but I don't see a "Cancel and
> restart builds" privilege.
>
> I think that's all that's needed - give me a shout if I've missed anything.
> Paul
>
>
> On 18 July 2017 at 19:07, Zachary Ware  wrote:
>> On Tue, Jul 18, 2017 at 12:23 PM, Brett Cannon  wrote:
>>> I set up the account and Zach has access. If you have instructions to point
>>> me at, Paul, I can see if I can set it up.
>>
>> Looks like https://ci.appveyor.com/gitHubTeams while logged in as 'python'.
>>
>> That looks like the right place to make the changes, anyway; I haven't
>> tried to actually make any :)
>>
>> --
>> Zach
>> ___
>> 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] My (positive) feedback on the new CPython workflow

[Brett Cannon]

On Tue, 18 Jul 2017 at 03:24 Victor Stinner 
wrote:

> Hi,
>
> 2017-07-18 11:36 GMT+02:00 Antoine Pitrou :
> > Can I take the opportunity to say thank you again (both you and Larry)
> > for the "blurb" tool?  It really makes an important difference when
> > contributing.
>

Glad it's working out! And a thanks from me to everyone who participated in
the discussions that led to blurb (and of course Larry for coding it up and
putting up with me throughout the whole process :) .


> >
> > Regards
> >
> > Antoine.
>
> I concur with Antoine, I'm now *very* happy with the new workflow. The
> code became better, many things are much simpler for me (especially
> the tasks that I don't have to do myself anymore ;-)), my productivity
> increases and I see more and more active contributors, much more than
> before the move to GitHub and new workflow!
>

Great! That was the goal the whole time so I'm glad it's starting to pay
off.


>
>
> == Introduction ==
>
> Two friends asked me recently how is the new Python workflow going.
>
> Somehow, I decided to not express myself on the topic to avoid dummy
> knee-jerk reaction like "it sucks, it was better before, xxx doesn't
> work, now I have to xxx, etc."
>
> It took me at least 3 months to be used to the new workflow, while
> tools were developed and enhanced, and the workflow was adjusted based
> on our early feedback.
>
> So, here is my feedback :-)
>
>
> == pre-commit CI: less regressions ==
>
> From a pure technical point of view, IMHO pre-commit CI on Linux
> (Travis CI) and Windows (AppVeyor) is a *MAJOR* enhancement. (I don't
> count macOS, since it's not mandatory yet.)
>
> For example, before GitHub, it was common to break Windows since too
> few core developers were running tests *manually* on Windows.
>
> It's hard to prove my point, so try to trust me: we reduce a lot the
> number of regressions introduced by new changesets. Before, every two
> weeks, we had to rush to push fixes in urgency (which sometimes leaded
> to bad code which required multiple iterations until we find the best
> fix).
>
> It was especially annoying when a dev pushed a big change just before
> being away for 8-12 hours, which means having to push a fix without
> the review of the change author :-(
>

I have to admit I also appreciate the CI testing a lot since I worry a lot
less about whether Python is in some broken state. And then thanks to all
the hard work you've done, Victor, we know that if the buildbots go red
that we have actually regressed and need to roll back a change instead of
going "that buildbot is just always broken so you can ignore it".

It's getting to the point that I'm toying with the idea of making a Google
Assistant command for my Google Home so I can say, "Hey Google, how is
CPython doing?" and have it tell me if the buildbots are all green. :) And
I still dream about having some LED light or grid for sprints where we can
visibly see the buildbot statuses to know quickly when something has
broken. But none of that was possible previously, so it's really exciting
to have reached a stability point where this isn't a stupid idea. :)


>
>
> == More contributors, more contributions, faster reviewed/merged ==
>
> In term of contributions, I looked at statistics yesterday and it
> became clear the number of different authors is significantely much
> higher, around 25 contributors / month before, now closer to 50:
> https://www.openhub.net/p/python/contributors/summary
>
> Well, Git allows to store the original author, so statistics are
> simplify higher just because previously the tools failed to identify
> the real author.
>

I'm going to be interested to see how the numbers look in Feb 2018 compared
to now and see if there's a trend since the transition.


>
> But I'm watching the bug tracker, pull requests, and Git commits:
> there are a lot of *new* contributors, we get more contributions, and
> we are *faster* to integrate them.
>
> I also saw again inactive core contributors starting to review again,
> or even write new PRs! It's a very good sign of the good health of our
> project!
>

As Serhiy pointed out, though, some people have not made the transition. To
help with this I plan on offering to do video chats with any core devs who
want a personal walkthrough of the workflow, but I'm holding off on that
until all of the critical workflow changes have landed as I don't want to
be talking with someone and saying, "but this will be changing in a month
or so". :)


>
> More generally, the whole development seems to be more active, more
> productive and more *healthy*.
>
>
> == Better scale horizontally ==
>
> The new workflow better scales horizontally since we delegated much
> more work to the contributor. Previously the core developers were more
> the bottleneck.
>
> Tasks delegated to the contributors:
>
> * create the PR itself (can you still remind when we had to download a
> patch file and create a commit? ;-)),
>
> * write the commit message (I always hated 

Re: [python-committers] My (positive) feedback on the new CPython workflow

[R. David Murray]

On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner  
wrote:
> I'm just not unconfortable with the fact that an approval is kept even
> if the PR is modified after the review :-/ I would expect a list a
> notice "changed modified after the review" or something like that. At
> least, for my own reviews, to remind me to review again.

This could be changed if we have consensus to do so.  Github has a
setting that will cause existing approvals to be "dismissed" if
a new commit is pushed.

> Compared to Rietveld, GitHub review tool is as "a good" (not much
> better, not much worse). Sometimes, I'm lost in reviews: my comments
> are hidden, I have to unfold many widgets. But it's not that bad. It
> seems like avoiding rebase works around some of these issues.

I much prefer rietveld over github reviews, but I also much prefer the
integration between the bug tracker and github over the minimal
integration we had for rietveld.  Thanks to all the people who made
that happen, and especially Brett for leading it.

--David
___
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] My (positive) feedback on the new CPython workflow

[Barry Warsaw]

On Jul 18, 2017, at 15:21, R. David Murray  wrote:
> 
> I much prefer rietveld over github reviews, but I also much prefer the
> integration between the bug tracker and github over the minimal
> integration we had for rietveld.  Thanks to all the people who made
> that happen, and especially Brett for leading it.

Not that I’m suggesting anything should change, but just FWIW, I find Gitlab to 
have a much better conversational review tool than Github.  I often find myself 
getting lost in GH reviews (on many projects), but GL just organizes the 
conversation really well IMHO.

Cheers,
-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] How do I kill an AppVeyor build?

[Brett Cannon]

On Tue, 18 Jul 2017 at 11:08 Zachary Ware 
wrote:

> On Tue, Jul 18, 2017 at 12:23 PM, Brett Cannon  wrote:
> > I set up the account and Zach has access. If you have instructions to
> point
> > me at, Paul, I can see if I can set it up.
>
> Looks like https://ci.appveyor.com/gitHubTeams while logged in as
> 'python'.
>
> That looks like the right place to make the changes, anyway; I haven't
> tried to actually make any :)
>

I went ahead and clicked buttons. :) I set Python core as users and release
managers as admins (on top of Zach and me already being admins).
___
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] Dismiss review if a PR is modified

[Victor Stinner]

2017-07-18 21:21 GMT+02:00 R. David Murray :
> On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner  
> wrote:
>> I'm just not unconfortable with the fact that an approval is kept even
>> if the PR is modified after the review :-/ I would expect a list a
>> notice "changed modified after the review" or something like that. At
>> least, for my own reviews, to remind me to review again.
>
> This could be changed if we have consensus to do so.  Github has a
> setting that will cause existing approvals to be "dismissed" if
> a new commit is pushed.
>
>> Compared to Rietveld, GitHub review tool is as "a good" (not much
>> better, not much worse). Sometimes, I'm lost in reviews: my comments
>> are hidden, I have to unfold many widgets. But it's not that bad. It
>> seems like avoiding rebase works around some of these issues.
>
> I much prefer rietveld over github reviews, but I also much prefer the
> integration between the bug tracker and github over the minimal
> integration we had for rietveld.  Thanks to all the people who made
> that happen, and especially Brett for leading it.

I am in favor of making this change :-)

Victor
___
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] How do I kill an AppVeyor build?

[Paul Moore]

On 18 July 2017 at 20:59, Brett Cannon  wrote:
> I went ahead and clicked buttons. :) I set Python core as users and release
> managers as admins (on top of Zach and me already being admins).

Cool - when I log in now I have "python" as an option. I can't restart
a build, but that's as expected - as admins, only RMs will be able to
restart or cancel builds.

It might be that adding the privilege "Projects -> Run Project Builds"
(either to the "Users" role or to a specific new role linked with the
core dev GH group) would give the ability to restart/cancel builds.
But I haven't tested that.

Paul
___
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] My (positive) feedback on the new CPython workflow

[Terry Reedy]

On 7/18/2017 2:31 PM, Brett Cannon wrote:

Once again, glad the goals are panning out. :) Key thing has always been 
to increase our bandwidth and part of that was always to push more on to 
contributors so they can be more self-servicing.



* most contributors create backports (using cherry-pick) themself.
Before, this painful/error-prone task was usually done by a single
developer without any review, without pre-commit tests, etc.


Backports affecting the same file should be done in the same order, with 
the same 'before' state.


  Real example: I merged PR A for file x.py and updated my clone to the 
result of the merge.  I then prepared and merged PR B for the same file. 
 Someone 'helpfully' prepared a backport of PR B, call it PR B3.6.  It 
passed CI but was wrong.  Fortunately, I checked the 'after' state of 
the file on a side-by-side diff. I prepared and merged PR A3.6, updated 
the 3.6 branck of my clone, and then prepared a new and correct backport 
of PR B.


Correct backporting is most easily assured if backports are done 
immediately.  I currently do so myself instead of requesting and waiting 
for a contributor to do so (who likely is not immediately available). 
Even better would be for the backport to happen automatically.




My wishlist that I don't think anyone is actively working on ATM is:


>  2. Bot to backport PRs (which could also be automatically merged)

So, to me, this is the priority item on the list.


 1. Bot to merge approved PRs (e.g. Rust's Homu)


How is a bot going to re-write the commit message?  Beside which, 
'approve' does not necessarily mean 'commit now'.



 3. Automate Misc/ACKS (or do away with it and do something like
https://thanks.rust-lang.org/)


Nice, but it is easy enough to ask the new contributor to do it ;-).


 4. Make test coverage reports consistent


First, we need to make sure that the only difference in the before and 
after code is the diff shown on the PR files pages, so that the coverage 
difference is only due to the actual patch.  From what I have seen, this 
does not seem true now.  One way to make this happen would be to update 
the PR (or a copy thereof) to current repository, so that the only files 
affected by the tested PR are the ones intended and visible.


Second, at least for IDLE, the .coveragerc file needs a few exclude 
lines added.  I suspect that they would be compatible with the rest of 
the tests.  (This could be checked with grep.)



 5. Automatically close stale PRs (e.g. not signing CLA, changes
requested but not being made, etc.)


What does 'close' (without merging) mean?  I would not want older (IDLE) 
PRs permanently gone in any sense just because I am busy reviewing other 
patches.  I recently merged PR based on a patch uploaded to BPO 8 years ago.


Not signing CLA is a special case.


 6. Bot to nudge core devs when they forget something (e.g. post-merge,
a comment if someone forgot to change the commit message or PR
number to have a "GH-" prefix)


When possible, I would prefer to get reminders before the merge.

--
Terry Jan Reedy


___
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] My (positive) feedback on the new CPython workflow

[Brett Cannon]

On Tue, 18 Jul 2017 at 12:54 Barry Warsaw  wrote:

> On Jul 18, 2017, at 15:21, R. David Murray  wrote:
> >
> > I much prefer rietveld over github reviews, but I also much prefer the
> > integration between the bug tracker and github over the minimal
> > integration we had for rietveld.  Thanks to all the people who made
> > that happen, and especially Brett for leading it.
>
> Not that I’m suggesting anything should change, but just FWIW, I find
> Gitlab to have a much better conversational review tool than Github.  I
> often find myself getting lost in GH reviews (on many projects), but GL
> just organizes the conversation really well IMHO.
>

It's very obvious, Barry, that you're playing the long game of trying to
line up GitLab as the next platform once we grow tired of GitHub and need
to switch in a few years. I'm on to you. ;)
___
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] My (positive) feedback on the new CPython workflow

[Brett Cannon]

On Tue, 18 Jul 2017 at 16:06 Terry Reedy  wrote:

> On 7/18/2017 2:31 PM, Brett Cannon wrote:
>
> > Once again, glad the goals are panning out. :) Key thing has always been
> > to increase our bandwidth and part of that was always to push more on to
> > contributors so they can be more self-servicing.
> >
> >
> > * most contributors create backports (using cherry-pick) themself.
> > Before, this painful/error-prone task was usually done by a single
> > developer without any review, without pre-commit tests, etc.
>
> Backports affecting the same file should be done in the same order, with
> the same 'before' state.
>
>Real example: I merged PR A for file x.py and updated my clone to the
> result of the merge.  I then prepared and merged PR B for the same file.
>   Someone 'helpfully' prepared a backport of PR B, call it PR B3.6.  It
> passed CI but was wrong.  Fortunately, I checked the 'after' state of
> the file on a side-by-side diff. I prepared and merged PR A3.6, updated
> the 3.6 branck of my clone, and then prepared a new and correct backport
> of PR B.
>
> Correct backporting is most easily assured if backports are done
> immediately.  I currently do so myself instead of requesting and waiting
> for a contributor to do so (who likely is not immediately available).
> Even better would be for the backport to happen automatically.
>
>
> > My wishlist that I don't think anyone is actively working on ATM is:
>

Just so people know, I'm not going to reply to any comments about the
wishlist since worrying about design details for something that doesn't
even have someone motivated enough to work on it is I think too premature
to worry about. I put this list here basically to see if something suddenly
garnered someone's interest to implement or to see if there was an
unexpected groundswell of interest to push it up the priority list. If any
of these ideas to get someone behind them then the discussion will end up
on the core-workflow mailing list.
___
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] How do I kill an AppVeyor build?

[Brett Cannon]

On Tue, 18 Jul 2017 at 13:33 Paul Moore  wrote:

> On 18 July 2017 at 20:59, Brett Cannon  wrote:
> > I went ahead and clicked buttons. :) I set Python core as users and
> release
> > managers as admins (on top of Zach and me already being admins).
>
> Cool - when I log in now I have "python" as an option. I can't restart
> a build, but that's as expected - as admins, only RMs will be able to
> restart or cancel builds.
>
> It might be that adding the privilege "Projects -> Run Project Builds"
> (either to the "Users" role or to a specific new role linked with the
> core dev GH group) would give the ability to restart/cancel builds.
> But I haven't tested that.
>

I had to delete the Python core team access, create a new type of role, and
then re-add the Python team access (sorry to anyone who logged in already
using that access, I think AppVeyor reset things), but I now have a role
where we can tweak settings and I added the "run project builds" to the
Super User role everyone has access through.
___
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] Dismiss review if a PR is modified

[Victor Stinner]

Oh.

For backports, it's convenient to be able to merge without a review. I see
many cores doing it and I like it.

For master, I don't know. Sometimes a PR is merged too fast, sometiles
nobody reviews a PR even if it's good. So for the master branch, the dev
takes its own responsability to merge ;-)

I only asked if it would be possible to dismiss an approval or mark the
review as outdated if the change is modified afterwards, but it seems like
GitHub doesn't offer many choices...

The current behaviour is okish. It was just a minor whish.

Victor


Le 19 juil. 2017 1:13 AM, "Brett Cannon"  a écrit :



On Tue, 18 Jul 2017 at 13:10 Victor Stinner 
wrote:

> 2017-07-18 21:21 GMT+02:00 R. David Murray :
> > On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner <
> victor.stin...@gmail.com> wrote:
> >> I'm just not unconfortable with the fact that an approval is kept even
> >> if the PR is modified after the review :-/ I would expect a list a
> >> notice "changed modified after the review" or something like that. At
> >> least, for my own reviews, to remind me to review again.
> >
> > This could be changed if we have consensus to do so.  Github has a
> > setting that will cause existing approvals to be "dismissed" if
> > a new commit is pushed.
> >
> >> Compared to Rietveld, GitHub review tool is as "a good" (not much
> >> better, not much worse). Sometimes, I'm lost in reviews: my comments
> >> are hidden, I have to unfold many widgets. But it's not that bad. It
> >> seems like avoiding rebase works around some of these issues.
> >
> > I much prefer rietveld over github reviews, but I also much prefer the
> > integration between the bug tracker and github over the minimal
> > integration we had for rietveld.  Thanks to all the people who made
> > that happen, and especially Brett for leading it.
>
> I am in favor of making this change :-)
>

Do realize that setting is part of requiring a review for pull requests:
https://help.github.com/articles/enabling-required-
reviews-for-pull-requests/. So in order to get this we would require all
PRs, core dev or not, to receive an approving review from another core
developer (I don't think an approving review from just anyone counts
towards the minimum approval). There might be around this, but it will
require some testing to make sure (see https://github.com/python/
core-workflow/issues/94#issuecomment-316224864).
___
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] Dismiss review if a PR is modified

[Brett Cannon]

On Tue, 18 Jul 2017 at 13:10 Victor Stinner 
wrote:

> 2017-07-18 21:21 GMT+02:00 R. David Murray :
> > On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner <
> victor.stin...@gmail.com> wrote:
> >> I'm just not unconfortable with the fact that an approval is kept even
> >> if the PR is modified after the review :-/ I would expect a list a
> >> notice "changed modified after the review" or something like that. At
> >> least, for my own reviews, to remind me to review again.
> >
> > This could be changed if we have consensus to do so.  Github has a
> > setting that will cause existing approvals to be "dismissed" if
> > a new commit is pushed.
> >
> >> Compared to Rietveld, GitHub review tool is as "a good" (not much
> >> better, not much worse). Sometimes, I'm lost in reviews: my comments
> >> are hidden, I have to unfold many widgets. But it's not that bad. It
> >> seems like avoiding rebase works around some of these issues.
> >
> > I much prefer rietveld over github reviews, but I also much prefer the
> > integration between the bug tracker and github over the minimal
> > integration we had for rietveld.  Thanks to all the people who made
> > that happen, and especially Brett for leading it.
>
> I am in favor of making this change :-)
>

Do realize that setting is part of requiring a review for pull requests:
https://help.github.com/articles/enabling-required-reviews-for-pull-requests/.
So in order to get this we would require all PRs, core dev or not, to
receive an approving review from another core developer (I don't think an
approving review from just anyone counts towards the minimum approval).
There might be around this, but it will require some testing to make sure
(see
https://github.com/python/core-workflow/issues/94#issuecomment-316224864).
___
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] My (positive) feedback on the new CPython workflow

[Mariatta Wijaya]

> >  2. Bot to backport PRs (which could also be automatically merged)
> So, to me, this is the priority item on the list.


I'm planning to work on the cherry-pick bot this during the core sprint in
September. Unless someone beat me to it.


Automatically close stale PRs (e.g. not signing CLA, changes
> requested but not being made, etc.)


This is also in my sprint plan, but only if I finish the cherry-pick bot :)
Further discussion can be done here:
https://github.com/python/core-workflow/issues/93



What does 'close' (without merging) mean?


The PR will be closed. The branch containing the changeset will still be
available in the contributor's fork of CPython.
Unless they delete it too.

On GitHub You can search for PRs that are closed but not merged by using
the filters:
is:pr is:closed is:unmerged

A list of closed PRs that were not merged
https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%
3Apr%20is%3Aclosed%20is%3Aunmerged%20

I believe the reopening the PR straight-forward: click on the "Reopen pull
request" button.


Mariatta Wijaya

On Tue, Jul 18, 2017 at 4:01 PM, Brett Cannon  wrote:

>
>
> On Tue, 18 Jul 2017 at 12:54 Barry Warsaw  wrote:
>
>> On Jul 18, 2017, at 15:21, R. David Murray  wrote:
>> >
>> > I much prefer rietveld over github reviews, but I also much prefer the
>> > integration between the bug tracker and github over the minimal
>> > integration we had for rietveld.  Thanks to all the people who made
>> > that happen, and especially Brett for leading it.
>>
>> Not that I’m suggesting anything should change, but just FWIW, I find
>> Gitlab to have a much better conversational review tool than Github.  I
>> often find myself getting lost in GH reviews (on many projects), but GL
>> just organizes the conversation really well IMHO.
>>
>
> It's very obvious, Barry, that you're playing the long game of trying to
> line up GitLab as the next platform once we grow tired of GitHub and need
> to switch in a few years. I'm on to you. ;)
>
> ___
> 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] Dismiss review if a PR is modified

[Nick Coghlan]

On 19 July 2017 at 09:37, Victor Stinner  wrote:
> Oh.
>
> For backports, it's convenient to be able to merge without a review. I see
> many cores doing it and I like it.
>
> For master, I don't know. Sometimes a PR is merged too fast, sometiles
> nobody reviews a PR even if it's good. So for the master branch, the dev
> takes its own responsability to merge ;-)

Right, "review required" settings can be useful, but they genuinely
require a self-review option as an escape hatch in community projects,
and GitHub doesn't currently offer that (it doesn't allow self-review
at all, not even to mark your own PRs as still requiring further
changes).

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] GitHub blog post on managing email notifications

[Brett Cannon]

Thought people might be interested in this post (specifically the email
header info) since I know some have said they have had issues in managing
email notifications:
https://github.com/blog/2399-managing-large-numbers-of-github-notifications
___
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] GitHub blog post on managing email notifications

[Guido van Rossum]

In a similar vein, I found the triangular workflow described here useful:
https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows

(TBH I don't follow the recipe exactly, but I do use upstream to point to
the master repo, origin to point to my own fork on GitHub, and I have

[remote]
pushdefault = origin
[push]
default = current

in my .git/config. Now every branch automatically gets pulled from upstream
and pushed to origin, the perfect setup for submitting Pull Requests.

On Tue, Jul 18, 2017 at 6:29 PM, Brett Cannon  wrote:

> Thought people might be interested in this post (specifically the email
> header info) since I know some have said they have had issues in managing
> email notifications: https://github.com/blog/2399-managing-large-
> numbers-of-github-notifications
>
> ___
> 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/