Re: [python-committers] New ncoghlan-bpo-29537-NEWS branch?

2017-03-10 Thread Brett Cannon 
FYI the clearing out of branches that are no longer open for development is
being discussed at https://github.com/python/core-workflow/issues/31

On Thu, 9 Mar 2017 at 17:08 Victor Stinner  wrote:

> Le 9 mars 2017 7:32 PM, "Brett Cannon"  a écrit :
>
> In general I expect none of those branches to live longer than 24 hours as
> the PRs they were created for should be merged in less than an hour. If a
> branch is older than a day then it means someone probably forgot to delete
> the branch after merging a PR.
>
>
> My main experience with Git is the OpenStack project and in this project
> there is no such "temporary" branches.
>
> I didn't know that it was possible to remove an "upstream" branch in Git.
>
> I will see in a few weeks if these branches are an issu in practice or not
> ;-)
>
> Right now, I'm still a little bit lost in the long list of branches. I
> have many local branches too.
>
> Victor
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

2017-03-10 Thread Brett Cannon 
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.

Fifth, anything I missed? :)
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

2017-03-10 Thread Donald Stufft 

> On Mar 10, 2017, at 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)

I agree with not wanting to turn off mandatory CI. It’d be nice to get as much 
coverage of platforms as we can as required CI on a per-merge basis, but there 
is obviously a balance to be had here between quick responses and maximal 
coverage.

> 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)

For the couple of things I’ve done I’ve not had any problem with it.

One thing I noticed that might be weird is that Misc/NEWS is kind of weird now. 
On `master` it only contains entries for 3.6 up until the point that 3.6 was 
branched off of `master` (or more specifically in this case, since we migrated 
to a cherry-picking work flow). This will likely cause some issues now that I 
think about it with the stuff in #python/core-workflow#6 because files added to 
`master` between the last release of X.Y and when X.Y gets branched off of 
`master` are going to show up as new in X.Y+1. This could be resolved I think 
by, immediately altering branching X.Y off of `master`, deleting all pending 
news files and also cherry-picking the “compile” step of say, 3.6 into the 
`master` branch (and so on up the line). Alternatively still do the delete 
thing, but make the ``Misc/NEWS`` specific to a particular release series.

> 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’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.

> 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
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/


—
Donald Stufft



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

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

2017-03-10 Thread 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
[email protected]
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?

2017-03-10 Thread 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
[email protected]
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?

2017-03-10 Thread 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
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/