Re: [python-committers] 4 weeks with the new workflow: what needs changing?

[Brett Cannon]

On Fri, 24 Mar 2017 at 06:26 Antoine Pitrou  wrote:

>
> Le 10/03/2017 à 23:13, Brett Cannon a écrit :
> > I can't believe it's been 4 weeks. It feels like it was ages/yesterday
> > when we moved. :)
> >
> > First, I hope people are not regretting letting/having me make this
> > migration. I know there have been some things to work through (and
> > others still to come), but I hope this is all a net positive (either now
> > or in the near future).
> >
> > Second, I wanted to get initial feedback on things we can easily tweak:
> >
> >   * Requiring Travis to pass (I *really* don't want to turn this off as
> > we already had a broken build when I temporarily turned it off at
> > someone's request when Travis was backed up from the AWS S3 outage;
> > I also don't plan to make AppVeyor required unless there's a way to
> > make it be skipped for doc-only changes)
> >   * Cherry-picking working out? (We can go back to forward merging if
> > people really want to, but I think long-term cherry-picking will
> > allow for more automation)
>
> Now that I'm trying it out, the effect of cherry-picking on Misc/NEWS is
> catastrophic.  hg wasn't very friendly (producing obviously spurious
> conflicts), but at least it was reasonably easy to correct the
> situation.  git seems to leave Misc/NEWS in an extremely messy state.
> For example, here is the merge diff I'm getting right now:
> https://gist.github.com/pitrou/37dd07d0136644266ca012e979c27847
>
> Good luck spotting devising how to fix Misc/NEWS after that (apart from
> retrieving the previous version and adding the NEWS entry manually)...
>

This is actively being worked on and I'm hoping to have it resolved in the
next week or so (I really don't see it going passed the end of this month,
but I would be absolutely shocked if it isn't fixed by May).
___
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] 4 weeks with the new workflow: what needs changing?

[R. David Murray]

On Fri, 24 Mar 2017 14:29:13 +0100, Antoine Pitrou  wrote:
> 
> By the way, how do I fetch remote changes for a branch without pulling
> it into the working copy?  e.g. I'd like to do "git fetch origin 3.5" or
> "git fetch origin/3.5", but that doesn't seem to work...

"git fetch origin 3.5" seems to work fine for me.  Maybe I don't
understand what you are trying to do?

--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] 4 weeks with the new workflow: what needs changing?

[Antoine Pitrou]

Le 10/03/2017 à 23:13, Brett Cannon a écrit :
> I can't believe it's been 4 weeks. It feels like it was ages/yesterday
> when we moved. :)
> 
> First, I hope people are not regretting letting/having me make this
> migration. I know there have been some things to work through (and
> others still to come), but I hope this is all a net positive (either now
> or in the near future).
> 
> Second, I wanted to get initial feedback on things we can easily tweak:
> 
>   * Requiring Travis to pass (I *really* don't want to turn this off as
> we already had a broken build when I temporarily turned it off at
> someone's request when Travis was backed up from the AWS S3 outage;
> I also don't plan to make AppVeyor required unless there's a way to
> make it be skipped for doc-only changes)
>   * Cherry-picking working out? (We can go back to forward merging if
> people really want to, but I think long-term cherry-picking will
> allow for more automation)

Right now, the way cherry-picking works (or doesn't really work, rather)
makes me likely to do "blind cherry-picks", that is try to fix conflicts
and trust the script's output without really bothering to inspect the
code locally, instead relying on Travis and AppVeyor.
I don't know if that's good for long-term quality.

I am more or less used to git, but it's the first time I have a
cherry-picking workflow (the other projects I work on don't really have
a notion of bugfix branch, or only an ephemeral one).  git seems to make
that extremely painful.

Really

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] 4 weeks with the new workflow: what needs changing?

[Antoine Pitrou]

By the way, how do I fetch remote changes for a branch without pulling
it into the working copy?  e.g. I'd like to do "git fetch origin 3.5" or
"git fetch origin/3.5", but that doesn't seem to work...

Regards

Antoine.



Le 24/03/2017 à 14:25, Antoine Pitrou a écrit :
> 
> Le 10/03/2017 à 23:13, Brett Cannon a écrit :
>> I can't believe it's been 4 weeks. It feels like it was ages/yesterday
>> when we moved. :)
>>
>> First, I hope people are not regretting letting/having me make this
>> migration. I know there have been some things to work through (and
>> others still to come), but I hope this is all a net positive (either now
>> or in the near future).
>>
>> Second, I wanted to get initial feedback on things we can easily tweak:
>>
>>   * Requiring Travis to pass (I *really* don't want to turn this off as
>> we already had a broken build when I temporarily turned it off at
>> someone's request when Travis was backed up from the AWS S3 outage;
>> I also don't plan to make AppVeyor required unless there's a way to
>> make it be skipped for doc-only changes)
>>   * Cherry-picking working out? (We can go back to forward merging if
>> people really want to, but I think long-term cherry-picking will
>> allow for more automation)
> 
> Now that I'm trying it out, the effect of cherry-picking on Misc/NEWS is
> catastrophic.  hg wasn't very friendly (producing obviously spurious
> conflicts), but at least it was reasonably easy to correct the
> situation.  git seems to leave Misc/NEWS in an extremely messy state.
> For example, here is the merge diff I'm getting right now:
> https://gist.github.com/pitrou/37dd07d0136644266ca012e979c27847
> 
> Good luck spotting devising how to fix Misc/NEWS after that (apart from
> retrieving the previous version and adding the NEWS entry manually)...
> 
> 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] 4 weeks with the new workflow: what needs changing?

[Antoine Pitrou]

Le 10/03/2017 à 23:13, Brett Cannon a écrit :
> I can't believe it's been 4 weeks. It feels like it was ages/yesterday
> when we moved. :)
> 
> First, I hope people are not regretting letting/having me make this
> migration. I know there have been some things to work through (and
> others still to come), but I hope this is all a net positive (either now
> or in the near future).
> 
> Second, I wanted to get initial feedback on things we can easily tweak:
> 
>   * Requiring Travis to pass (I *really* don't want to turn this off as
> we already had a broken build when I temporarily turned it off at
> someone's request when Travis was backed up from the AWS S3 outage;
> I also don't plan to make AppVeyor required unless there's a way to
> make it be skipped for doc-only changes)
>   * Cherry-picking working out? (We can go back to forward merging if
> people really want to, but I think long-term cherry-picking will
> allow for more automation)

Now that I'm trying it out, the effect of cherry-picking on Misc/NEWS is
catastrophic.  hg wasn't very friendly (producing obviously spurious
conflicts), but at least it was reasonably easy to correct the
situation.  git seems to leave Misc/NEWS in an extremely messy state.
For example, here is the merge diff I'm getting right now:
https://gist.github.com/pitrou/37dd07d0136644266ca012e979c27847

Good luck spotting devising how to fix Misc/NEWS after that (apart from
retrieving the previous version and adding the NEWS entry manually)...

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] 4 weeks with the new workflow: what needs changing?

[Brett Cannon]

https://github.com/python/core-workflow/issues/13 already exists to track
this idea, so it can be discussed more over there.

On Thu, 16 Mar 2017 at 10:26 Barry Warsaw  wrote:

> On Mar 16, 2017, at 04:14 PM, Brett Cannon wrote:
>
> >Ah, you didn't say you wanted this to be a status check. :) Do we want to
> >go so far as that rather than a comment or PR template?
>
> I like it for that on my other projects, so I'm pretty sure I'd like that
> for
> CPython.  I'm a big fan of more automated checks -when they are stable and
> robust- for doing the fiddly little checks that are a pain to do
> manually.  I
> like requiring bug reports for most things, plus style checks, etc.  It
> makes
> it so much easier for a submitter to conform because they get immediate
> feedback if they break some policy.  There's usually a strong drive to get
> all
> the lights green.
>
> Cheers,
> -Barry
> ___
> 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] 4 weeks with the new workflow: what needs changing?

[Barry Warsaw]

On Mar 16, 2017, at 04:14 PM, Brett Cannon wrote:

>Ah, you didn't say you wanted this to be a status check. :) Do we want to
>go so far as that rather than a comment or PR template?

I like it for that on my other projects, so I'm pretty sure I'd like that for
CPython.  I'm a big fan of more automated checks -when they are stable and
robust- for doing the fiddly little checks that are a pain to do manually.  I
like requiring bug reports for most things, plus style checks, etc.  It makes
it so much easier for a submitter to conform because they get immediate
feedback if they break some policy.  There's usually a strong drive to get all
the lights green.

Cheers,
-Barry


pgpdE0ayCcSq6.pgp
Description: OpenPGP digital signature
___
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] 4 weeks with the new workflow: what needs changing?

[Yury Selivanov]

On 2017-03-16 12:16 PM, Brett Cannon wrote:



On Wed, 15 Mar 2017 at 20:24 R. David Murray > wrote:


On Wed, 15 Mar 2017 22:56:33 -0400, Yury Selivanov
> wrote:
> It's not just long waiting times (although it's a huge factor), it's
> that you have to create temporary branches for cherry-picks. With
> scripts or without, it's a lot of bookkeeping. Also, interacting
with a
> console is still much more convenient than using web tools (at
least for
> me).

+100 :)


I'm afraid this one is going to come down to personal preference 
because I actually pref the web UI. :) But we will keep working at 
this to see if we can't find a happy medium somehow.



I just discovered this handy tool: https://github.com/github/hub. Will 
try to use it and will share my experience.


Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] 4 weeks with the new workflow: what needs changing?

[Brett Cannon]

On Wed, 15 Mar 2017 at 20:24 R. David Murray  wrote:

> On Wed, 15 Mar 2017 22:56:33 -0400, Yury Selivanov <
> yselivanov...@gmail.com> wrote:
> > It's not just long waiting times (although it's a huge factor), it's
> > that you have to create temporary branches for cherry-picks. With
> > scripts or without, it's a lot of bookkeeping. Also, interacting with a
> > console is still much more convenient than using web tools (at least for
> > me).
>
> +100 :)
>

I'm afraid this one is going to come down to personal preference because I
actually pref the web UI. :) But we will keep working at this to see if we
can't find a happy medium somehow.
___
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] 4 weeks with the new workflow: what needs changing?

[Brett Cannon]

On Wed, 15 Mar 2017 at 17:03 Barry Warsaw  wrote:

> On Mar 16, 2017, at 12:00 AM, Brett Cannon wrote:
>
> >But that would require that external contributors know to set that label
> >ahead of time and I'm willing to bet most won't.
>
> Not if the test has a retry feature.  Your change is trivial but you didn't
> add the label.  The test fails.  You add the label and retry the test.
> Now it
> passes.
>

Ah, you didn't say you wanted this to be a status check. :) Do we want to
go so far as that rather than a comment or PR template?
___
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] 4 weeks with the new workflow: what needs changing?

[M.-A. Lemburg]

On 16.03.2017 00:49, Brett Cannon wrote:
> On Wed, 15 Mar 2017 at 08:44 Berker Peksağ  wrote:
> 
>> On Mon, Mar 13, 2017 at 12:11 AM, Brett Cannon  wrote:
>>>
>>>
>>> On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg  wrote:

 On 10.03.2017 23:13, Brett Cannon wrote:
> Fifth, anything I missed? :)

 My main nit after the move is that messages to the checkin list
 no longer include the full patch. This makes reviews harder than
 necessary (you always have to go through the browser).

 Is there some way this could be changed back to what we had
 previously or is this a hard limitation of github ?
>>>
>>>
>>> It's a hard limitation of the GitHub-provided email solution. With
>> GitHub's
>>> APIs and enough time someone could either come up with a custom email
>>> solution or a web page that showed this information (you literally just
>> need
>>> to add ".diff" to the end of a URL to get the diff itself for a PR, e.g.
>>> https://github.com/python/cpython/pull/648.diff will redirect to a raw
>>> diff). There might also already be other solutions out there that do what
>>> you're after.
>>>
>>> Obviously this all requires work on someone's part. :) (I've also moved
>>> completely off of an email-based workflow so I'm definitely not the right
>>> person to drive this sort of thing.)
>>
>> I wrote https://github.com/berkerpeksag/cpython-emailer-webhook to
>> solve this problem. It works and its output is almost same as the old
>> one [1] I even wrote some tests and documentation, but I just noticed
>> that I forgot to push to GitHub :)
>>
>> If we all agree on the idea I can help with deploying it. I can use my
>> own VPS for the initial deploy, but it would be nice to have a PSF
>> backed server in the long term.

This would be fantastic :-) Thank you, Berker !

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Mar 16 2017)
>>> 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
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] 4 weeks with the new workflow: what needs changing?

[R. David Murray]

On Wed, 15 Mar 2017 22:56:33 -0400, Yury Selivanov  
wrote:
> It's not just long waiting times (although it's a huge factor), it's 
> that you have to create temporary branches for cherry-picks. With 
> scripts or without, it's a lot of bookkeeping. Also, interacting with a 
> console is still much more convenient than using web tools (at least for 
> me).

+100 :)

--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] 4 weeks with the new workflow: what needs changing?

[Yury Selivanov]

Hi Brett,

On 2017-03-14 6:00 PM, Brett Cannon wrote:
[..]



Yesterday I was working on a few asyncio PRs and a bug in async/await.
All PRs required cherry-picking.  Again, I was spending significant
amount of time just creating branches/PRs for cherry-picking.


Were you creating the branches manually or using Mariatta's script?


I'll check it out!


  Again
waiting for CI checks (even though I always run the test suite
before I
push).  In the end of the day, I was so frustrated and discouraged
that
I just stopped working on CPython.


Our Travis runs just got increased today so this should be improved. 
As I have also previously said we can consider scaling back the number 
of things we're building if necessary (i.e. we could go as low as 3 
instead of the 5 we currently have or trying building using g++ to 
combine gcc and the C++ header check).


Yeah, reducing the number of tasks would really help.  Anything that can 
make required CI checks quicker.


It's a double-edged sword when you don't gate on CI but you have it 
for all PRs. When Serhiy accidentally broke the build when I turned 
off Travis gating for you, all PRs for a few hours came in as failing 
and it confused some external contributors as to why their PR was 
coming up red.


Ah, OK, I now better understand the rationale for requiring CI pass.

[..]
 If all of those things are tried and we are still seeing unacceptably 
long wait times on PRs, then we can talk about turning off the CI 
gating. Does that seem fair?


It's not just long waiting times (although it's a huge factor), it's 
that you have to create temporary branches for cherry-picks. With 
scripts or without, it's a lot of bookkeeping. Also, interacting with a 
console is still much more convenient than using web tools (at least for 
me).


Anyways, while I don't totally enjoy the current workflow I see why it 
is as it is right now. I'll try to get used to it.


Thank you,
Yury

P.S. Thanks to everybody who's been working on GH migration. Overall 
it's a very positive change!


___
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] 4 weeks with the new workflow: what needs changing?

[Barry Warsaw]

On Mar 16, 2017, at 12:00 AM, Brett Cannon wrote:

>But that would require that external contributors know to set that label
>ahead of time and I'm willing to bet most won't.

Not if the test has a retry feature.  Your change is trivial but you didn't
add the label.  The test fails.  You add the label and retry the test.  Now it
passes.

-Barry


pgpemjhCBMZFe.pgp
Description: OpenPGP digital signature
___
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] 4 weeks with the new workflow: what needs changing?

[Brett Cannon]

On Tue, 14 Mar 2017 at 16:26 Barry Warsaw  wrote:

> On Mar 14, 2017, at 06:16 PM, Ned Deily wrote:
>
> >There is one pattern that is happening fairly often and that I think we
> >should do something about.  That is, non-committers submitting a PR
> without
> >first opening an issue on BPO.  It gets very old fast trying to enforce
> that.
> >Perhaps one of the bots could flag PRs that do not have a BPO ref in their
> >titles?
>
> Should there be a way to override that?  In another project of mine on GH,
> we
> use a 'trivial' tag on the PR to bypass that check.
>

But that would require that external contributors know to set that label
ahead of time and I'm willing to bet most won't.

I see two ways of solving this. One is to have a bot that leaves a comment
when an issue isn't seen, otherwise it leaves a comment with a link back to
the original issue for easy access. The other is we add a PR template that
mentions that the title should include a reference to the issue for
anything but the most trivial PR (and to create an issue
otherwise).Obviously there's a great variance in effort required but also
with the usefulness of what the solution does.
___
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] 4 weeks with the new workflow: what needs changing?

[Brett Cannon]

On Wed, 15 Mar 2017 at 08:44 Berker Peksağ  wrote:

> On Mon, Mar 13, 2017 at 12:11 AM, Brett Cannon  wrote:
> >
> >
> > On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg  wrote:
> >>
> >> On 10.03.2017 23:13, Brett Cannon wrote:
> >> > Fifth, anything I missed? :)
> >>
> >> My main nit after the move is that messages to the checkin list
> >> no longer include the full patch. This makes reviews harder than
> >> necessary (you always have to go through the browser).
> >>
> >> Is there some way this could be changed back to what we had
> >> previously or is this a hard limitation of github ?
> >
> >
> > It's a hard limitation of the GitHub-provided email solution. With
> GitHub's
> > APIs and enough time someone could either come up with a custom email
> > solution or a web page that showed this information (you literally just
> need
> > to add ".diff" to the end of a URL to get the diff itself for a PR, e.g.
> > https://github.com/python/cpython/pull/648.diff will redirect to a raw
> > diff). There might also already be other solutions out there that do what
> > you're after.
> >
> > Obviously this all requires work on someone's part. :) (I've also moved
> > completely off of an email-based workflow so I'm definitely not the right
> > person to drive this sort of thing.)
>
> I wrote https://github.com/berkerpeksag/cpython-emailer-webhook to
> solve this problem. It works and its output is almost same as the old
> one [1] I even wrote some tests and documentation, but I just noticed
> that I forgot to push to GitHub :)
>
> If we all agree on the idea I can help with deploying it. I can use my
> own VPS for the initial deploy, but it would be nice to have a PSF
> backed server in the long term.
>

I believe we have free Heroku resources to putting it there should be easy
(the infrastructure team would know best obviously where we have free
resources).

-Brett


>
> --Berker
>
> [1]
> https://github.com/python/core-workflow/issues/24#issuecomment-279162079
>
___
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] 4 weeks with the new workflow: what needs changing?

[Berker Peksağ]

On Mon, Mar 13, 2017 at 12:11 AM, Brett Cannon  wrote:
>
>
> On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg  wrote:
>>
>> On 10.03.2017 23:13, Brett Cannon wrote:
>> > Fifth, anything I missed? :)
>>
>> My main nit after the move is that messages to the checkin list
>> no longer include the full patch. This makes reviews harder than
>> necessary (you always have to go through the browser).
>>
>> Is there some way this could be changed back to what we had
>> previously or is this a hard limitation of github ?
>
>
> It's a hard limitation of the GitHub-provided email solution. With GitHub's
> APIs and enough time someone could either come up with a custom email
> solution or a web page that showed this information (you literally just need
> to add ".diff" to the end of a URL to get the diff itself for a PR, e.g.
> https://github.com/python/cpython/pull/648.diff will redirect to a raw
> diff). There might also already be other solutions out there that do what
> you're after.
>
> Obviously this all requires work on someone's part. :) (I've also moved
> completely off of an email-based workflow so I'm definitely not the right
> person to drive this sort of thing.)

I wrote https://github.com/berkerpeksag/cpython-emailer-webhook to
solve this problem. It works and its output is almost same as the old
one [1] I even wrote some tests and documentation, but I just noticed
that I forgot to push to GitHub :)

If we all agree on the idea I can help with deploying it. I can use my
own VPS for the initial deploy, but it would be nice to have a PSF
backed server in the long term.

--Berker

[1] https://github.com/python/core-workflow/issues/24#issuecomment-279162079
___
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] 4 weeks with the new workflow: what needs changing?

[Ned Deily]

On Mar 14, 2017, at 19:25, Barry Warsaw  wrote:
> On Mar 14, 2017, at 06:16 PM, Ned Deily wrote:
>> There is one pattern that is happening fairly often and that I think we
>> should do something about.  That is, non-committers submitting a PR without
>> first opening an issue on BPO.  It gets very old fast trying to enforce that.
>> Perhaps one of the bots could flag PRs that do not have a BPO ref in their
>> titles?
> Should there be a way to override that?  In another project of mine on GH, we
> use a 'trivial' tag on the PR to bypass that check.

Sure, something like that would be fine.

--
  Ned Deily
  n...@python.org -- []

___
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] 4 weeks with the new workflow: what needs changing?

[Barry Warsaw]

On Mar 14, 2017, at 06:16 PM, Ned Deily wrote:

>There is one pattern that is happening fairly often and that I think we
>should do something about.  That is, non-committers submitting a PR without
>first opening an issue on BPO.  It gets very old fast trying to enforce that.
>Perhaps one of the bots could flag PRs that do not have a BPO ref in their
>titles?

Should there be a way to override that?  In another project of mine on GH, we
use a 'trivial' tag on the PR to bypass that check.

Cheers,
-Barry
___
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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 10, 2017, at 5:13 PM, Brett Cannon  wrote:
> 
> Is the mention bot helpful? (Our config is at 
> https://github.com/python/cpython/blob/master/.mention-bot 
>  and the docs are 
> at https://github.com/facebook/mention-bot 
> )


Just as an FYI, I’ve turned the mention-bot down from mentioning a max of 5 to 
a max of 3 reviewers. I’m not sure if this is going to help or not, but at the 
very least it will reduce the number of people getting notified (and thus 
hopefully, the total number of notifications). If the touched-it-last algorithm 
is still not useful then that might be all the more it helps, but it might also 
be a problem trying to get too many useful reviewers out of touched-it-last.

—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[Ned Deily]

On Mar 14, 2017, at 18:05, Brett Cannon  wrote:
> There has been discussion of about coming up with some bot that would post a 
> message on service A when there's been comments on service B, although I 
> don't know how much that would help (nor which way the comments would go, 
> e.g. comment on GH that there's stuff on bugs.python.org or the other way 
> around?). Basically we all just need to be better about keeping only code 
> review discussions on GH and all other discussions on bugs.python.org. The 
> other way is to always have a welcome message stating this fact (whether 
> that's on every PR or only in the CLA message I don't know), but I don't know 
> if that would help either.

There is one pattern that is happening fairly often and that I think we should 
do something about.  That is, non-committers submitting a PR without first 
opening an issue on BPO.  It gets very old fast trying to enforce that.  
Perhaps one of the bots could flag PRs that do not have a BPO ref in their 
titles?

--
  Ned Deily
  n...@python.org -- []

___
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] 4 weeks with the new workflow: what needs changing?

[Brett Cannon]

On Sun, 12 Mar 2017 at 19:11 Raymond Hettinger 
wrote:

>
> > On Mar 10, 2017, at 2:13 PM, Brett Cannon  wrote:
> >
> > I wanted to get initial feedback on things we can easily tweak:
>
> Overall, the new workflow is mostly positive.  The tooling looks great and
> it seems to have increased the number of participants.
>
> There is a disconnect between discussions on the tracker and discussions
> on the bug tracker. It would be nice if discussions could be better
> synchronized.
>

There has been discussion of about coming up with some bot that would post
a message on service A when there's been comments on service B, although I
don't know how much that would help (nor which way the comments would go,
e.g. comment on GH that there's stuff on bugs.python.org or the other way
around?). Basically we all just need to be better about keeping only code
review discussions on GH and all other discussions on bugs.python.org. The
other way is to always have a welcome message stating this fact (whether
that's on every PR or only in the CLA message I don't know), but I don't
know if that would help either.

-Brett


>
> There does seem to be some confusion on when it is okay to commit.  At
> least one core dev is of the opinion that if tests are passing it is okay
> for him to approve and commit regardless of area of expertise, status of
> the tracker item, or approval of the module maintainer.  IMO, having the
> tests pass is a pretty low bar and seems to bypass consideration of whether
> the change is the right thing to do.
>
> For me personally, I've not yet had time to read through all the new
> processes, the new devguide,and  to get my git/github skills up-to-date, so
> I've been completely left behind (not a single patch or build since the
> migration).  I'm hoping that I can get caught up over some upcoming
> weekend, but the migration did create a whole new set of challenges that
> I've never had in the last 16 years of core development.  For the time
> being, I'm mostly helpless and can only comment here are there on various
> issues.
>
> For people who have more time on their hands or who were already familiar
> which all the tooling, the migration seems to have been much easier.
>
>
> Raymond
>
>
>
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] 4 weeks with the new workflow: what needs changing?

[Brett Cannon]

On Mon, 13 Mar 2017 at 09:48 Yury Selivanov  wrote:

> Hi,
>
> First, I'm really happy that we moved to git and GH.  The GH review tool
> is super convenient and CI integration helps.
>
> I'm less happy about requiring to make a PR for every commit. It's a no
> problem for new features development, but it's a huge pain for a bug
> fixing workflow.  Last week I needed to push a bunch of bug fixes to
> 3.7/3.6/3.5.  I had about 6 pull requests to the master branch, + 12
> more for 3.6 and 3.5.  I basically killed my entire second half of the
> day waiting until CI checks clear out.  I spend a few hours pushing just
> 3 (!!) committs to all branches.  Thanks to Brett, who disabled the push
> CI check for a while, I was able to push the remaining 3 bug fixes and
> their cherry picks in under 10 minutes.
>
> Yesterday I was working on a few asyncio PRs and a bug in async/await.
> All PRs required cherry-picking.  Again, I was spending significant
> amount of time just creating branches/PRs for cherry-picking.


Were you creating the branches manually or using Mariatta's script?


>   Again
> waiting for CI checks (even though I always run the test suite before I
> push).  In the end of the day, I was so frustrated and discouraged that
> I just stopped working on CPython.
>

Our Travis runs just got increased today so this should be improved. As I
have also previously said we can consider scaling back the number of things
we're building if necessary (i.e. we could go as low as 3 instead of the 5
we currently have or trying building using g++ to combine gcc and the C++
header check).


>
> The current workflow makes it significantly harder for me to be
> productive.  At this point I'm so discouraged of working on any bug
> fixes that I consider to stop working on them until the full
> cherry-picking automation is implemented.
>
> So I guess what I'm asking for is to consider turning the CI/PR push
> requirement off until we have automatic cherry-picking and a new NEWS
> file workflow.  We lived without this check for many years with
> mercurial.  Yes, all of us pushed some broken commits, but we have
> buildbots and CI, so nothing horrible ever happended.
>

It's a double-edged sword when you don't gate on CI but you have it for all
PRs. When Serhiy accidentally broke the build when I turned off Travis
gating for you, all PRs for a few hours came in as failing and it confused
some external contributors as to why their PR was coming up red. I had to
tell people that it was already broken before their PR was submitted and
once the fix was in that they needed to rebase to make sure their tests
pass. And the only way to make this not be an issue without gating on CI is
to require all PRs to be fully rebased before merging which is a constant
merge race (which we all know from our forward merging days to be a massive
pain and would then also require all PRs be merged through the command-line
and never online in order to do the rebase for contributors who would
always be behind).

IOW having CI is somewhat of an all-or-nothing thing here, else you are
dealing with the fallout of a broken build for a while (compared to the
Mercurial days where we all did the rebasing manually along with testing in
order to avoid this issue). Now as Donald pointed out, our concurrency
levels went up this morning so hopefully that will help with this.

It also doesn't help when randomness schedules test_tools, test_datetime,
or test_tokenize towards the end of a test run since they all take a few
minutes under clang (don't know why specifically clang, but there you go).

My point is that there are still some things we can do to make the
turn-around time on CI to be faster: see if the slower tests could be sped
up, deciding if we need all builds that we currently have, seeing if our
new concurrency levels help, or even consider gating on AppVeyor instead of
Travis. If all of those things are tried and we are still seeing
unacceptably long wait times on PRs, then we can talk about turning off the
CI gating. Does that seem fair?

-Brett


>
> Thank you,
> Yury
>
>
> On 2017-03-10 5:13 PM, Brett Cannon wrote:
> > I can't believe it's been 4 weeks. It feels like it was ages/yesterday
> > when we moved. :)
> >
> > First, I hope people are not regretting letting/having me make this
> > migration. I know there have been some things to work through (and
> > others still to come), but I hope this is all a net positive (either
> > now or in the near future).
> >
> > Second, I wanted to get initial feedback on things we can easily tweak:
> >
> >   * Requiring Travis to pass (I *really* don't want to turn this off
> > as we already had a broken build when I temporarily turned it off
> > at someone's request when Travis was backed up from the AWS S3
> > outage; I also don't plan to make AppVeyor required unless there's
> > a way to make it be skipped for doc-only changes)
> >   * Cherry-picking working out? (We 

Re: [python-committers] 4 weeks with the new workflow: what needs changing?

[Brett Cannon]

On Mon, 13 Mar 2017 at 12:36 R. David Murray  wrote:

> On Mon, 13 Mar 2017 12:48:30 -0400, Yury Selivanov <
> yselivanov...@gmail.com> wrote:
> > Yesterday I was working on a few asyncio PRs and a bug in async/await.
> > All PRs required cherry-picking.  Again, I was spending significant
> > amount of time just creating branches/PRs for cherry-picking.  Again
> > waiting for CI checks (even thougn I always run the test suite before I
> > push).  In the end of the day, I was so frustrated and discouraged that
> > I just stopped working on CPython.
>
> Branch management was always the most time consuming part of committing,
> even under HG.  But github has clearly made it worse.  Personally I doubt
> I'm going to do any backports if I'm required to go visit some web pages
> to do it.  That doesn't matter much, since I don't have much time for
> contribution and have done very few checkins in a good while (even before
> the switch).  But Brett was hoping that github would make it *easier* to
> get stuff merged, and from my perspective that is only true for doc fixes
> (which, granted, is a help :), while making it harder for code fixes.
>
> So, I think the backport-bot should probably be the top priority of
> whoever has time to work on this (which, unfortunately, is not me :(
>

It's #2 after the Misc/NEWS solution.

-Brett


>
> Being able to backport without going through the PR process would also
> make sense to me (and I thought we were going to be able to do that),
> but I'm not involved enough in the conversations to know the downsides
> of that.
>
___
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] 4 weeks with the new workflow: what needs changing?

[Alex Gaynor]

If most patches (by LOC) don't require domain knowledge to commit, I guess
they probably don't need domain knowledge to review.

Alex

On Tue, Mar 14, 2017 at 5:07 PM, Brett Cannon  wrote:

>
>
> On Mon, 13 Mar 2017 at 10:04 Donald Stufft  wrote:
>
>>
>> On Mar 13, 2017, at 11:54 AM, Barry Warsaw  wrote:
>>
>> I actually kind of like the idea of a mentionbot, but the current
>> implementation has some problems.  Rather than calculating who should be
>> mentioned based on TIL (touched it last), it would be nicer if this got
>> closer
>> to solving Raymond's comment.  If the domain expert could be notified
>> when PRs
>> touch stuff they care about, that might be better.  The mentionbot could
>> then
>> be opt-in for folks who want to see more detail.
>>
>>
>>
>> So mention-bot supports that, it just needs configured
>>
>
> Specifically, if you look at https://github.com/facebook/mention-bot and
> note the alwaysNotifyForPaths option. The problem is what happens to the
> experts file? If we end up managing both that file and the mentionbot
> confis separately then it leads to a bifurcation of where we track that
> info. At that point we have to either consider something to use to easily
> update one based on the other (e.g. pull in the experts file and use it to
> update the mentionbot config), or we come up with our own solution to the
> problem.
>
>
>> . I suspect though that it’s touched-it-last mentioning will get better
>> once we get more people with commits under their actual name.
>>
>
> As I think Antoine pointed out, if people are doing fixes that don't
> require domain knowledge then that can skew the results (whether that will
> skew that much I don't know).
>
> -Brett
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
___
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] 4 weeks with the new workflow: what needs changing?

[Brett Cannon]

On Mon, 13 Mar 2017 at 10:04 Donald Stufft  wrote:

>
> On Mar 13, 2017, at 11:54 AM, Barry Warsaw  wrote:
>
> I actually kind of like the idea of a mentionbot, but the current
> implementation has some problems.  Rather than calculating who should be
> mentioned based on TIL (touched it last), it would be nicer if this got
> closer
> to solving Raymond's comment.  If the domain expert could be notified when
> PRs
> touch stuff they care about, that might be better.  The mentionbot could
> then
> be opt-in for folks who want to see more detail.
>
>
>
> So mention-bot supports that, it just needs configured
>

Specifically, if you look at https://github.com/facebook/mention-bot and
note the alwaysNotifyForPaths option. The problem is what happens to the
experts file? If we end up managing both that file and the mentionbot
confis separately then it leads to a bifurcation of where we track that
info. At that point we have to either consider something to use to easily
update one based on the other (e.g. pull in the experts file and use it to
update the mentionbot config), or we come up with our own solution to the
problem.


> . I suspect though that it’s touched-it-last mentioning will get better
> once we get more people with commits under their actual name.
>

As I think Antoine pointed out, if people are doing fixes that don't
require domain knowledge then that can skew the results (whether that will
skew that much I don't know).

-Brett
___
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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 12, 2017, at 9:12 PM, Brett Cannon  wrote:
> 
> Already have. We got 25 jobs shared between python, pypa, and pyca thanks to 
> Donald. At this point the best option we have to speed things up is to 
> consider dropping tests (e.g. do we want to keep the C++ header test, or do 
> we really need to test both clang and gcc?).



Just to let everyone know, this hadn’t been activated yet, but as of this 
morning it is. So we should now be getting 25 concurrent jobs shared between 
the three projects. I think this will work out well because it gives us 25 job 
burst and it’s unlikely that all orgs are having high activity at the same time 
(except maybe at something like PyCon, but that is going to be an issue either 
way ;) ).


—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[R. David Murray]

On Mon, 13 Mar 2017 12:48:30 -0400, Yury Selivanov  
wrote:
> Yesterday I was working on a few asyncio PRs and a bug in async/await.  
> All PRs required cherry-picking.  Again, I was spending significant 
> amount of time just creating branches/PRs for cherry-picking.  Again 
> waiting for CI checks (even thougn I always run the test suite before I 
> push).  In the end of the day, I was so frustrated and discouraged that 
> I just stopped working on CPython.

Branch management was always the most time consuming part of committing,
even under HG.  But github has clearly made it worse.  Personally I doubt
I'm going to do any backports if I'm required to go visit some web pages
to do it.  That doesn't matter much, since I don't have much time for
contribution and have done very few checkins in a good while (even before
the switch).  But Brett was hoping that github would make it *easier* to
get stuff merged, and from my perspective that is only true for doc fixes
(which, granted, is a help :), while making it harder for code fixes.

So, I think the backport-bot should probably be the top priority of
whoever has time to work on this (which, unfortunately, is not me :(

Being able to backport without going through the PR process would also
make sense to me (and I thought we were going to be able to do that),
but I'm not involved enough in the conversations to know the downsides
of that.

--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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 13, 2017, at 11:54 AM, Barry Warsaw  wrote:
> 
> I actually kind of like the idea of a mentionbot, but the current
> implementation has some problems.  Rather than calculating who should be
> mentioned based on TIL (touched it last), it would be nicer if this got closer
> to solving Raymond's comment.  If the domain expert could be notified when PRs
> touch stuff they care about, that might be better.  The mentionbot could then
> be opt-in for folks who want to see more detail.


So mention-bot supports that, it just needs configured. I suspect though that 
it’s touched-it-last mentioning will get better once we get more people with 
commits under their actual name.

—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[Yury Selivanov]

Hi,

First, I'm really happy that we moved to git and GH.  The GH review tool 
is super convenient and CI integration helps.


I'm less happy about requiring to make a PR for every commit. It's a no 
problem for new features development, but it's a huge pain for a bug 
fixing workflow.  Last week I needed to push a bunch of bug fixes to 
3.7/3.6/3.5.  I had about 6 pull requests to the master branch, + 12 
more for 3.6 and 3.5.  I basically killed my entire second half of the 
day waiting until CI checks clear out.  I spend a few hours pushing just 
3 (!!) committs to all branches.  Thanks to Brett, who disabled the push 
CI check for a while, I was able to push the remaining 3 bug fixes and 
their cherry picks in under 10 minutes.


Yesterday I was working on a few asyncio PRs and a bug in async/await.  
All PRs required cherry-picking.  Again, I was spending significant 
amount of time just creating branches/PRs for cherry-picking.  Again 
waiting for CI checks (even thougn I always run the test suite before I 
push).  In the end of the day, I was so frustrated and discouraged that 
I just stopped working on CPython.


The current workflow makes it significantly harder for me to be 
productive.  At this point I'm so discouraged of working on any bug 
fixes that I consider to stop working on them until the full 
cherry-picking automation is implemented.


So I guess what I'm asking for is to consider turning the CI/PR push 
requirement off until we have automatic cherry-picking and a new NEWS 
file workflow.  We lived without this check for many years with 
mercurial.  Yes, all of us pushed some broken commits, but we have 
buildbots and CI, so nothing horrible ever happended.


Thank you,
Yury


On 2017-03-10 5:13 PM, Brett Cannon wrote:
I can't believe it's been 4 weeks. It feels like it was ages/yesterday 
when we moved. :)


First, I hope people are not regretting letting/having me make this 
migration. I know there have been some things to work through (and 
others still to come), but I hope this is all a net positive (either 
now or in the near future).


Second, I wanted to get initial feedback on things we can easily tweak:

  * Requiring Travis to pass (I *really* don't want to turn this off
as we already had a broken build when I temporarily turned it off
at someone's request when Travis was backed up from the AWS S3
outage; I also don't plan to make AppVeyor required unless there's
a way to make it be skipped for doc-only changes)
  * Cherry-picking working out? (We can go back to forward merging if
people really want to, but I think long-term cherry-picking will
allow for more automation)
  o Along with that, are the labels for cherry-picking working
out? (Some devs seem to like using title labels like `[3.6]`
to flag cherry-picks so it's more obvious in emails so I don't
know if the labels are really that useful)
  * Is the mention bot helpful? (Our config is at
https://github.com/python/cpython/blob/master/.mention-bot and the
docs are at https://github.com/facebook/mention-bot)
  * Anything to tweak about the coverage bot and reports? (Our config
is at
https://github.com/python/cpython/blob/master/.codecov.yml and
docs at https://docs.codecov.io/docs/codecov-yaml)

Third, I wanted to point out some of the more critical discussions 
going on at https://github.com/python/core-workflow/issues. 
Specifically, https://github.com/python/core-workflow/issues/6 is 
working towards a solution for Misc/NEWS so if you care about the 
final solution you should participate there. After Misc/NEWS is solved 
the next step becomes solving the cherry-picking overhead with a more 
automated approach. We are also discussing closed branches to make the 
list of branches more manageable at 
https://github.com/python/core-workflow/issues/31.


Fourth, the lack of messages showing up on bugs.python.org 
 after a commit is being tracked at 
http://psf.upfronthosting.co.za/roundup/meta/issue613. I'm sure Ezio 
and Maciej would appreciate any help people may be able to volunteer 
to help in solving the problem.


Fifth, anything I missed? :)


___
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] 4 weeks with the new workflow: what needs changing?

[Antoine Pitrou]

Le 13/03/2017 à 16:56, Alex Gaynor a écrit :
> That suggests an interesting question: Why is the Touched It Last so
> different from the domain expert :-)

Because there are many changes which don't necessitate a domain expert's
intervention (such as replacing one argument-parsing API with another).

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] 4 weeks with the new workflow: what needs changing?

[Alex Gaynor]

That suggests an interesting question: Why is the Touched It Last so
different from the domain expert :-)

Alex

On Mon, Mar 13, 2017 at 11:54 AM, Barry Warsaw  wrote:

> On Mar 13, 2017, at 01:12 AM, Brett Cannon wrote:
>
> >Since there doesn't seem to be strong support I'm leaning towards
> switching
> >it off as well, but I will wait until there's been at least a weekday
> >around the globe for people to notice this email thread.
>
> I actually kind of like the idea of a mentionbot, but the current
> implementation has some problems.  Rather than calculating who should be
> mentioned based on TIL (touched it last), it would be nicer if this got
> closer
> to solving Raymond's comment.  If the domain expert could be notified when
> PRs
> touch stuff they care about, that might be better.  The mentionbot could
> then
> be opt-in for folks who want to see more detail.
>
> -Barry
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
___
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] 4 weeks with the new workflow: what needs changing?

[Barry Warsaw]

On Mar 13, 2017, at 01:12 AM, Brett Cannon wrote:

>Since there doesn't seem to be strong support I'm leaning towards switching
>it off as well, but I will wait until there's been at least a weekday
>around the globe for people to notice this email thread.

I actually kind of like the idea of a mentionbot, but the current
implementation has some problems.  Rather than calculating who should be
mentioned based on TIL (touched it last), it would be nicer if this got closer
to solving Raymond's comment.  If the domain expert could be notified when PRs
touch stuff they care about, that might be better.  The mentionbot could then
be opt-in for folks who want to see more detail.

-Barry
___
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] 4 weeks with the new workflow: what needs changing?

[Barry Warsaw]

I agree that overall the new workflow is great.  I haven't done a ton of
commits, but the ones I did went very smoothly (modulo the known and hopefully
soon to be fixed Misc/News conflicts).  I also love being able to do reviews
on GH, and I think the more testing automation we can do, the better.  I'm
actually okay with trading run time for quality checks run automatically.

On Mar 12, 2017, at 07:11 PM, Raymond Hettinger wrote:

>There is a disconnect between discussions on the tracker and discussions on
>the bug tracker. It would be nice if discussions could be better
>synchronized.

This is a pretty common problem given that comments can occur in both places.
IME, it actually doesn't even matter that we're using two different systems;
I've seen it when the entire project is on the same hosting platform.

>There does seem to be some confusion on when it is okay to commit.  At least
>one core dev is of the opinion that if tests are passing it is okay for him
>to approve and commit regardless of area of expertise, status of the tracker
>item, or approval of the module maintainer.  IMO, having the tests pass is a
>pretty low bar and seems to bypass consideration of whether the change is the
>right thing to do.

This *is* a problem, although I would state it slightly differently.  It's
good to have module/domain experts and I definitely want such experts to be
active and involved in discussions around their areas of expertise, but I also
don't want to disempower people from approving changes that seem reasonable.
My worry is that strict ownership is a disincentive and paralyzing force for
improvements.

OTOH, how do we decide when a change is "good"?  I'm tracking and reviewing
the $PYTHONHISTORY change.  *I* think it's a good idea, and haven't seen any
compelling arguments against it.  I also really appreciate a few other people
weighing in (PR#473).  I plan on approving it once the code's in shape and the
tests all pass.  Maybe other people will hate it, but that's why we have
version control I suppose.

>For me personally, I've not yet had time to read through all the new
>processes, the new devguide,and to get my git/github skills up-to-date, so
>I've been completely left behind (not a single patch or build since the
>migration).  I'm hoping that I can get caught up over some upcoming weekend,
>but the migration did create a whole new set of challenges that I've never
>had in the last 16 years of core development.  For the time being, I'm mostly
>helpless and can only comment here are there on various issues.
>
>For people who have more time on their hands or who were already familiar
>which all the tooling, the migration seems to have been much easier.

Yes, I think that's true, and that means that patience will be required, both
from new contributors when their patches take time to land, and in ourselves
for our own changes.  I know I was rather impatient when reviews were
required, but I kind of think that might be a good thing (though not in all
cases).

If you've made it this far, one of the things I'm thinking about is removing
the [Python-checkins] Subject prefix from that mailing list.  It's mostly
redundant given that GH is *also* adding a [python/cpython] prefix[*], though
not entirely since non-GH automation like the daily reference leak doesn't
include it.  I like to see more content in the Subject.

Personal annoyance: GH's threading algorithm plays havoc with my MUA's default
display.  I haven't dug into it yet, but I always see later replies earlier in
the thread view, which is counter to every other conversation I read via
email.

I'm still *really* missing diffs in commit messages.

Cheers,
-Barry

[*] If someone knows a Mailman developer, it might be nice to request some
plugin to do custom Subject mangling.  
___
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] 4 weeks with the new workflow: what needs changing?

[Nick Coghlan]

On 12 March 2017 at 23:58, R. David Murray  wrote:

> On Sun, 12 Mar 2017 11:37:21 -, Paul Moore 
> wrote:
> > I don't have a problem with the new "PRs attached to this issue" field
> > - that's of course important to have. But is there any way to not have
> > them generate emails (probably on a per-user basis, as I'm sure
> > there's people who appreciate emails when PRs are added)? I guess the
> > other option is a client-side filter, but I'm not sure how easy it
> > would be to do something like that.
>
> Kind of telling that Nick asked for a "notify when PR created" feature,
> and you are asking for it to be disabled :)  Yes, it would need to be
> a per-user setting, and currently it is not (it is a global setting
> in Roundup).
>

I think what I actually want is for the current notifications to be more
useful, mainly by including the GitHub PR URL, rather than the
internal-to-roundup numeric PR ID.

I'd just forgotten about them until Paul mentioned them, as they're not
particularly useful right now :)

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] 4 weeks with the new workflow: what needs changing?

[Raymond Hettinger]

> On Mar 10, 2017, at 2:13 PM, Brett Cannon  wrote:
> 
> I wanted to get initial feedback on things we can easily tweak:

Overall, the new workflow is mostly positive.  The tooling looks great and it 
seems to have increased the number of participants.

There is a disconnect between discussions on the tracker and discussions on the 
bug tracker. It would be nice if discussions could be better synchronized.

There does seem to be some confusion on when it is okay to commit.  At least 
one core dev is of the opinion that if tests are passing it is okay for him to 
approve and commit regardless of area of expertise, status of the tracker item, 
or approval of the module maintainer.  IMO, having the tests pass is a pretty 
low bar and seems to bypass consideration of whether the change is the right 
thing to do.

For me personally, I've not yet had time to read through all the new processes, 
the new devguide,and  to get my git/github skills up-to-date, so I've been 
completely left behind (not a single patch or build since the migration).  I'm 
hoping that I can get caught up over some upcoming weekend, but the migration 
did create a whole new set of challenges that I've never had in the last 16 
years of core development.  For the time being, I'm mostly helpless and can 
only comment here are there on various issues.

For people who have more time on their hands or who were already familiar which 
all the tooling, the migration seems to have been much easier.


Raymond



___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] 4 weeks with the new workflow: what needs changing?

[R. David Murray]

On Sun, 12 Mar 2017 11:37:21 -, Paul Moore  wrote:
> I don't have a problem with the new "PRs attached to this issue" field
> - that's of course important to have. But is there any way to not have
> them generate emails (probably on a per-user basis, as I'm sure
> there's people who appreciate emails when PRs are added)? I guess the
> other option is a client-side filter, but I'm not sure how easy it
> would be to do something like that.

Kind of telling that Nick asked for a "notify when PR created" feature,
and you are asking for it to be disabled :)  Yes, it would need to be
a per-user setting, and currently it is not (it is a global setting
in Roundup).

I'm sure upstream would accept a patch to add a per-user setting for
this (and other things!).  Since the nosy emails are generated by a
reactor (a code snippet specific to the tracker instance) it wouldn't
even *need* to go upstream, and wouldn't be all that hard to write,
I think.  I'm not volunteering, though, not enough time :(

Maybe with the new docker tracker-test-setup that Maciej and Ezio have
refined we'll be able to get more volunteers interested in working
on the tracker codebase.  When they are ready it could use a bit more
visibility (a posting to python-dev and one to core-mentorship, say).

--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] 4 weeks with the new workflow: what needs changing?

[M.-A. Lemburg]

On 10.03.2017 23:13, Brett Cannon wrote:
> Fifth, anything I missed? :)

My main nit after the move is that messages to the checkin list
no longer include the full patch. This makes reviews harder than
necessary (you always have to go through the browser).

Is there some way this could be changed back to what we had
previously or is this a hard limitation of github ?

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


: Try our mxODBC.Connect Python Database Interface for free ! ::

   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/
___
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] 4 weeks with the new workflow: what needs changing?

[Paul Moore]

On 10 March 2017 at 22:13, Brett Cannon  wrote:
> Fifth, anything I missed? :)

One thing, somewhat peripheral. Since the move, issues on bpo now get
PRs added to them. That's fine, but it further reduces the signal to
noise ratio on the emails sent out for an issue (it was always bad,
with emails sent every time someone added or removed themselves from
the nosy list, and things like that, this just makes things a little
worse). Ideally, I'd like to only get emails when new messages are
added to the issue, but I don't think that's possible.

I don't have a problem with the new "PRs attached to this issue" field
- that's of course important to have. But is there any way to not have
them generate emails (probably on a per-user basis, as I'm sure
there's people who appreciate emails when PRs are added)? I guess the
other option is a client-side filter, but I'm not sure how easy it
would be to do something like 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] 4 weeks with the new workflow: what needs changing?

[Nick Coghlan]

On 11 March 2017 at 08:13, Brett Cannon  wrote:

> I can't believe it's been 4 weeks. It feels like it was ages/yesterday
> when we moved. :)
>
> First, I hope people are not regretting letting/having me make this
> migration. I know there have been some things to work through (and others
> still to come), but I hope this is all a net positive (either now or in the
> near future).
>
> Second, I wanted to get initial feedback on things we can easily tweak:
>
>- Requiring Travis to pass (I *really* don't want to turn this off as
>we already had a broken build when I temporarily turned it off at someone's
>request when Travis was backed up from the AWS S3 outage; I also don't plan
>to make AppVeyor required unless there's a way to make it be skipped for
>doc-only changes)
>
> I think this is a good thing, but it's annoying some times when processing
a change that needs to go to all 4 currently active branches. The other
case where it's annoying is when backfilling NEWS entries - if there's a
backlog, then it still takes a while to get to the point of Travis
detecting that there isn't actually anything for Travis to do.

It's probably worth talking to the PSF and Travis CI to see if it's
possible to speed things up a bit or get more parallel workers (some of the
PSF's larger sponsors are actually providing in-kind donations of services
rather than purely financial sponsorship).

>
>- Cherry-picking working out? (We can go back to forward merging if
>people really want to, but I think long-term cherry-picking will allow for
>more automation)
>
> I'm still a fan of cherry picking, as it simplifies the typical case to
"fix master, worry about backports later".

>
>- Along with that, are the labels for cherry-picking working out?
>   (Some devs seem to like using title labels like `[3.6]` to flag
>   cherry-picks so it's more obvious in emails so I don't know if the 
> labels
>   are really that useful)
>
> There was at least one PR submitter confused in IRC today as to whether or
not the "Needs backport to..." labels were asking *them* to do something.


>
>- Is the mention bot helpful? (Our config is at
>https://github.com/python/cpython/blob/master/.mention-bot
> and the
>docs are at https://github.com/facebook/mention-bot)
>
> Honestly, I'm starting to think we're going to have to tweak it a bit (or
come up with our own variant) to get something suitable for a primarily
volunteer-based development team, rather than the primarily paid teams that
I believe the mention-bot was originally written for. As it currently
stands, it's veering too far into burnout-inducing "Have you done enough
for CPython lately?" territory for my liking:
https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-an-open-source-maintainer/

So I'd personally vote for this to be turned off until there's a way to run
it in an *opt-in* configuration, rather than the current opt-out setup.

Another possibility would be to tweak the GitHub/bugs.python.org bridge to
add comments for PR *creation*, such that everyone on the nosy list gets
the alert that the PR exists (hence implicitly requesting a review from the
maintainers following the issue). That way things would better align with
the entries we've added to the experts index.

>
>- Anything to tweak about the coverage bot and reports? (Our config is
>at https://github.com/python/cpython/blob/master/.codecov.yml and docs
>at https://docs.codecov.io/docs/codecov-yaml)
>
> I was going to ask if there was a way to get the "Details" link to go
straight to a useful report, but it seems like that may have already been
tweaked.


> Third, I wanted to point out some of the more critical discussions going
> on at https://github.com/python/core-workflow/issues. Specifically,
> https://github.com/python/core-workflow/issues/6 is working towards a
> solution for Misc/NEWS so if you care about the final solution you should
> participate there. After Misc/NEWS is solved the next step becomes solving
> the cherry-picking overhead with a more automated approach.
>

For the cherry-picking automation, I've been very happy with Mariatta's
utility, and I believe that with a few robustness tweaks and a
conflict-avoiding approach to handling Misc/NEWS it would be up to the task
of generating the actual PRs as well. (The other side of the bot that
actually handled the interaction with GitHub could presumably be modeled on
the way the existing knights-who-say-ni bot works)

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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 11, 2017, at 9:30 PM, Martin Panter  wrote:
> 
> I am also aware of
>  > but
> haven’t added myself there yet.


Yea this is what I meant, adding your name to the ``userBlacklist`` array.

—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[Mariatta Wijaya]

>
> Requiring Travis to pass


Yes please.

 Cherry-picking working out?

Works for me. And I've done a lot of this :)

are the labels for cherry-picking working out?

I like the [3.6] Prefix (Thanks Berker for suggesting it originally)
I think [cherry-pick for  3.6] label is still useful as a visual cue in the
GitHub Web UI, but it does create extra work for core devs to apply the
labels. Perhaps won't be an issue once the cherry-pick bot is in place?
Anyway, I think we should keep both :)

Is the mention bot helpful?
>
I think if we can reduce the number of reviewers from 5 to 3 or 2, it might
reduce the amount of spam people are getting?
When someone starts blacklisting themselves from the mention-bot, it
just means that another person will now get spammed, and then decided to
blacklist themselves too.

anything I missed?

I'm wishing for an easy way to differentiate/identify PRs where:
- It's been reviewed, changes were requested, but author has not
responded/made updates. --> so don't bother reviewing
- It's been reviewed, changes were requested, and author has updated the
PR. --> so it's ready for another look
At the moment, both of these scenarios are shown as  "Changes Requested" in
GitHub web UI. It's hard to determine whether it's time to re-review the PR
or not.

Maybe we can add [wip] in the title after we requested the change. Once PR
author made further changes, they can remove the [wip].

Right now, cherry-picking is very annoying but I'm not sure that
> merging would be much better with the PR requirement.  I'm looking
> forward to automation!


I have a semi-automated command line script here:
https://github.com/mariatta/chic_a_cherry_picker
Please try it out :) I've cherry-picked quite a number of commits with this.
Works well when you don't anticipate any merge conflicts :)

The command line is something like:
$ python -m cherry_picker some-commit-sha1 3.6 3.5
It will do the cherry-pick and opens up web browser for creating the PR,
with head and base branches preselected.
All you need to do is enter [3.5] or [3.6] in the description, and press
the shiny green 'Create Pull Request' button.

Related: here's a list of merged PRs that need backporting to 3.6
https://github.com/python/cpython/pulls?utf8=%E2%9C%93=is%3Apr%20label%3A%22needs%20backport%20to%203.6%22%20is%3Amerged%20


Overall, I'm positive on the move.  Thanks for continuing to shepherd
> the migration, Brett!

+1.Thanks!



Mariatta Wijaya

On Sat, Mar 11, 2017 at 8:05 AM, Donald Stufft  wrote:

>
> On Mar 11, 2017, at 3:03 AM, Zachary Ware 
> wrote:
>
>
> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs
> are
> at https://github.com/facebook/mention-bot)
>
>
> I think so, it has prompted me to give a quick review on a couple of
> PRs.  It is occasionally annoying, but it's not hard to ignore.  I can
> see how it would be *very* annoying for anyone who has touched large
> swaths of the codebase, though.  If there's a way to make it opt-in,
> perhaps we could give that a spin?
>
>
>
> There’s no way to make it opt-in except by having people explicitly list
> what files they want to be notified on (either on an always basis, or on a
> “if you couldn’t find enough people through your heuristics” basis).
>
> —
> Donald Stufft
>
>
>
>
> ___
> 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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 11, 2017, at 3:03 AM, Zachary Ware  
> wrote:
> 
>> 
>> Is the mention bot helpful? (Our config is at
>> https://github.com/python/cpython/blob/master/.mention-bot 
>>  and the docs are
>> at https://github.com/facebook/mention-bot 
>> )
> 
> I think so, it has prompted me to give a quick review on a couple of
> PRs.  It is occasionally annoying, but it's not hard to ignore.  I can
> see how it would be *very* annoying for anyone who has touched large
> swaths of the codebase, though.  If there's a way to make it opt-in,
> perhaps we could give that a spin?


There’s no way to make it opt-in except by having people explicitly list what 
files they want to be notified on (either on an always basis, or on a “if you 
couldn’t find enough people through your heuristics” basis).

—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[Zachary Ware]

On Fri, Mar 10, 2017 at 4:13 PM, Brett Cannon  wrote:
> Requiring Travis to pass (I really don't want to turn this off as we already
> had a broken build when I temporarily turned it off at someone's request
> when Travis was backed up from the AWS S3 outage; I also don't plan to make
> AppVeyor required unless there's a way to make it be skipped for doc-only
> changes)

See GH-611.  I hadn't actually thought about that yet, but it turns
out to be pretty easy.

Also, I'm for keeping the Travis requirement, and also requiring
AppVeyor once we've ironed out some flaky tests.

> Cherry-picking working out? (We can go back to forward merging if people
> really want to, but I think long-term cherry-picking will allow for more
> automation)

Right now, cherry-picking is very annoying but I'm not sure that
merging would be much better with the PR requirement.  I'm looking
forward to automation!

> Along with that, are the labels for cherry-picking working out? (Some devs
> seem to like using title labels like `[3.6]` to flag cherry-picks so it's
> more obvious in emails so I don't know if the labels are really that useful)

I've considered whether I'd prefer having separate 'cherry-pick',
'needs backport', and 'x.y' labels rather than 'cherry-pick for x.y'
and 'needs backport to x.y'.  The separate 'x.y' labels would be
useful for issues that only pertain to a particular branch, but
requires selecting two separate labels when marking a PR as a
cherry-pick.  I'm not sure which I would actually prefer, I'm just
throwing the idea out there.

> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
> at https://github.com/facebook/mention-bot)

I think so, it has prompted me to give a quick review on a couple of
PRs.  It is occasionally annoying, but it's not hard to ignore.  I can
see how it would be *very* annoying for anyone who has touched large
swaths of the codebase, though.  If there's a way to make it opt-in,
perhaps we could give that a spin?

> Anything to tweak about the coverage bot and reports? (Our config is at
> https://github.com/python/cpython/blob/master/.codecov.yml and docs at
> https://docs.codecov.io/docs/codecov-yaml)

I haven't been noticing much of anything from the coverage bot since
we disallowed its comments.

Overall, I'm positive on the move.  Thanks for continuing to shepherd
the migration, Brett!

-- 
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] 4 weeks with the new workflow: what needs changing?

[Ezio Melotti]

On Sat, Mar 11, 2017 at 12:13 AM, Brett Cannon  wrote:
> I can't believe it's been 4 weeks. It feels like it was ages/yesterday when
> we moved. :)
>
> First, I hope people are not regretting letting/having me make this
> migration. I know there have been some things to work through (and others
> still to come), but I hope this is all a net positive (either now or in the
> near future).
>
> Second, I wanted to get initial feedback on things we can easily tweak:
>
> Requiring Travis to pass (I really don't want to turn this off as we already
> had a broken build when I temporarily turned it off at someone's request
> when Travis was backed up from the AWS S3 outage; I also don't plan to make
> AppVeyor required unless there's a way to make it be skipped for doc-only
> changes)
> Cherry-picking working out? (We can go back to forward merging if people
> really want to, but I think long-term cherry-picking will allow for more
> automation)
>
> Along with that, are the labels for cherry-picking working out? (Some devs
> seem to like using title labels like `[3.6]` to flag cherry-picks so it's
> more obvious in emails so I don't know if the labels are really that useful)
>
> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
> at https://github.com/facebook/mention-bot)
> Anything to tweak about the coverage bot and reports? (Our config is at
> https://github.com/python/cpython/blob/master/.codecov.yml and docs at
> https://docs.codecov.io/docs/codecov-yaml)
>
> Third, I wanted to point out some of the more critical discussions going on
> at https://github.com/python/core-workflow/issues. Specifically,
> https://github.com/python/core-workflow/issues/6 is working towards a
> solution for Misc/NEWS so if you care about the final solution you should
> participate there. After Misc/NEWS is solved the next step becomes solving
> the cherry-picking overhead with a more automated approach. We are also
> discussing closed branches to make the list of branches more manageable at
> https://github.com/python/core-workflow/issues/31.
>
> Fourth, the lack of messages showing up on bugs.python.org after a commit is
> being tracked at http://psf.upfronthosting.co.za/roundup/meta/issue613. I'm
> sure Ezio and Maciej would appreciate any help people may be able to
> volunteer to help in solving the problem.
>

I'm planning to look at this next week (if Maciej doesn't beat me to it).
FTR we have been working on a docker container that contains a test
instance of the tracker: https://github.com/python/docker-bpo/
Even though there are still a few rough edges, it's now pretty
straightforward to get a test tracker up and running.
Next we are planning to make a script to test/debug GitHub payloads
(so I can easily debug issue613) and eventually we will put the image
on DockerHub.

> Fifth, anything I missed? :)
>

I find the documentation in the devguide still lacking.
I've been trying to improve it, but first I have to figure out all the
details of the new workflow.

Best Regards,
Ezio Melotti
___
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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 10, 2017, at 8:38 PM, Martin Panter  wrote:
> 
>> On Mar 10, 2017, at 5:13 PM, Brett Cannon  wrote:
>> Is the mention bot helpful? (Our config is at
>> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
>> at https://github.com/facebook/mention-bot)
> 
> On 11 March 2017 at 00:32, Donald Stufft  wrote:
>> I’ve found it helpful thus far. It’s poked me on a  few issues and I jumped
>> in and gave a review on them. There is too much churn in python/cpython for
>> me to get notified of every issue. I suspect as we get more people
>> submitting PRs (and thus, retaining author) it will get more diverse in who
>> it notifies as well.
> 
> I dislike it. At the moment I have the Git Hub repository blocked, but
> this means I can’t even subscribe myself to interesting threads any
> more. I think there were way too many useless emails (lacking context,
> uninteresting to me, etc). It is automated spam.
> 
> I encourage you to remove it, or at least make it opt-in. Perhaps you
> can encourage contributors to look themselves at the “experts” list,
> history of the relevant code, or whatever, to find potential people to
> invite to a Git Hub discussion.


You know you can tell it not to message you?


—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[Martin Panter]

> On Mar 10, 2017, at 5:13 PM, Brett Cannon  wrote:
> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
> at https://github.com/facebook/mention-bot)

On 11 March 2017 at 00:32, Donald Stufft  wrote:
> I’ve found it helpful thus far. It’s poked me on a  few issues and I jumped
> in and gave a review on them. There is too much churn in python/cpython for
> me to get notified of every issue. I suspect as we get more people
> submitting PRs (and thus, retaining author) it will get more diverse in who
> it notifies as well.

I dislike it. At the moment I have the Git Hub repository blocked, but
this means I can’t even subscribe myself to interesting threads any
more. I think there were way too many useless emails (lacking context,
uninteresting to me, etc). It is automated spam.

I encourage you to remove it, or at least make it opt-in. Perhaps you
can encourage contributors to look themselves at the “experts” list,
history of the relevant code, or whatever, to find potential people to
invite to a Git Hub discussion.
___
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/