4 weeks with the new workflow: what needs changing?
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)
- Along with that, are the labels for cherry-picking working out?
(Some devs seem to like using title labels like
- 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? :)
On Mar 10, 2017, at 5:13 PM, Brett Cannon <brett@python.org> 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 <https://github.com/python/cpython/blob/master/.mention-bot> and the docs are at https://github.com/facebook/mention-bot <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 <https://github.com/python/cpython/blob/master/.codecov.yml> and docs at https://docs.codecov.io/docs/codecov-yaml <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 <https://github.com/python/core-workflow/issues>. Specifically, https://github.com/python/core-workflow/issues/6 <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 <https://github.com/python/core-workflow/issues/31>.
Fourth, the lack of messages showing up on bugs.python.org <http://bugs.python.org/> after a commit is being tracked at http://psf.upfronthosting.co.za/roundup/meta/issue613 <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/
— Donald Stufft
On Mar 10, 2017, at 5:13 PM, Brett Cannon <brett@python.org> 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 <donald@stufft.io> 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.
On Mar 10, 2017, at 8:38 PM, Martin Panter <vadmium+py@gmail.com> wrote:
On Mar 10, 2017, at 5:13 PM, Brett Cannon <brett@python.org> 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 <donald@stufft.io> 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
On Mar 10, 2017, at 5:13 PM, Brett Cannon <brett@python.org> 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 Mar 10, 2017, at 8:38 PM, Martin Panter <vadmium+py@gmail.com> wrote: 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.
On 11 March 2017 at 01:39, Donald Stufft <donald@stufft.io> wrote:
You know you can tell it not to message you?
I have tried <https://github.com/mention-bot/how-to-unsubscribe>, but that didn’t seem to have much effect. At least, I was still getting subscribed to new pull requests after blocking the bot.
I am also aware of <https://github.com/python/cpython/blob/master/.mention-bot> but haven’t added myself there yet.
On Mar 11, 2017, at 9:30 PM, Martin Panter <vadmium+py@gmail.com> wrote:
I am also aware of <https://github.com/python/cpython/blob/master/.mention-bot <https://github.com/python/cpython/blob/master/.mention-bot>> but haven’t added myself there yet.
Yea this is what I meant, adding your name to the userBlacklist array.
— Donald Stufft
On Sat, Mar 11, 2017 at 12:13 AM, Brett Cannon <brett@python.org> 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
On Fri, Mar 10, 2017 at 4:13 PM, Brett Cannon <brett@python.org> 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
On Mar 11, 2017, at 3:03 AM, Zachary Ware <zachary.ware+pydev@gmail.com> wrote:
Is the mention bot helpful? (Our config is at https://github.com/python/cpython/blob/master/.mention-bot <https://github.com/python/cpython/blob/master/.mention-bot> and the docs are at https://github.com/facebook/mention-bot <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
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&q=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 <donald@stufft.io> wrote:
On Mar 11, 2017, at 3:03 AM, Zachary Ware <zachary.ware+pydev@gmail.com> 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/
On 11 March 2017 at 08:13, Brett Cannon <brett@python.org> 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 <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-m...
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 | ncoghlan@gmail.com | Brisbane, Australia
On Sun, 12 Mar 2017 at 04:10 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 11 March 2017 at 08:13, Brett Cannon <brett@python.org> 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).
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?).
- 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.
I'm not quite sure how to solve that one beyond what is in the devguide. And did anyone have an opinion on (I think) Mariatta's idea to cut the labels down to versions + "needs backport" and "cherry-pick"?
- 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-m...
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.
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.
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)
We could consider moving the script to the core-workflow repo if Mariatta is amenable so that we can all contribute towards improving it and making it the short/medium-term solution until we have some bot to do the work (which could theoretically use the script itself).
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
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 <barry@python.org> 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
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.
On Mar 13, 2017, at 11:54 AM, Barry Warsaw <barry@python.org> 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
On Mon, 13 Mar 2017 at 10:04 Donald Stufft <donald@stufft.io> wrote:
On Mar 13, 2017, at 11:54 AM, Barry Warsaw <barry@python.org> 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
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 <brett@python.org> wrote:
On Mon, 13 Mar 2017 at 10:04 Donald Stufft <donald@stufft.io> wrote:
On Mar 13, 2017, at 11:54 AM, Barry Warsaw <barry@python.org> 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
On Mar 12, 2017, at 9:12 PM, Brett Cannon <brett@python.org> 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
On 10 March 2017 at 22:13, Brett Cannon <brett@python.org> 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 them generate emails (probably on a per-user basis, as I'm sure
- that's of course important to have. But is there any way to not have
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
On Sun, 12 Mar 2017 11:37:21 -0000, Paul Moore <p.f.moore@gmail.com> wrote:
I don't have a problem with the new "PRs attached to this issue" field them generate emails (probably on a per-user basis, as I'm sure
- that's of course important to have. But is there any way to not have
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
On 12 March 2017 at 13:58, R. David Murray <rdmurray@bitdance.com> wrote:
On Sun, 12 Mar 2017 11:37:21 -0000, Paul Moore <p.f.moore@gmail.com> wrote:
I don't have a problem with the new "PRs attached to this issue" field them generate emails (probably on a per-user basis, as I'm sure
- that's of course important to have. But is there any way to not have
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).
Yeah. Personally, I find that I can skim messages, but notifications (status changes, PRs added, nosy changes, etc) distract me badly. As a result, when the ratio of notifications gets too high, I end up feeling like I have no real option but to unsubscribe altogether, which reduces my involvement drastically. That's not an issue with the github move per se - prior to github I was basically ignoring all bpo traffic for precisely that reason anyway. The move has generated a lot *more* traffic that I haven't filtered yet (things like the devguide and workflow issue mails) plus the review mails on PRs, and that prompted me to try to be more selective in my filtering rather than just switching everything off blindly. Unfortunately, I ended up switching off PR emails as there wasn't enough context without the bpo messages, and I may yet switch off the others and go back to my old mode of operation. But it did make me think nevertheless (hence this message).
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,
As I've no knowledge of Roundup, and not a huge amount of spare time, I probably won't get round to doing this, but thanks for the pointer.
Paul
On 12 March 2017 at 23:58, R. David Murray <rdmurray@bitdance.com> wrote:
On Sun, 12 Mar 2017 11:37:21 -0000, Paul Moore <p.f.moore@gmail.com> wrote:
I don't have a problem with the new "PRs attached to this issue" field them generate emails (probably on a per-user basis, as I'm sure
- that's of course important to have. But is there any way to not have
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 | ncoghlan@gmail.com | Brisbane, Australia
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/
On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg <mal@egenix.com> 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.)
On Mon, Mar 13, 2017 at 12:11 AM, Brett Cannon <brett@python.org> wrote:
On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg <mal@egenix.com> 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
On Wed, 15 Mar 2017 at 08:44 Berker Peksağ <berker.peksag@gmail.com> wrote:
On Mon, Mar 13, 2017 at 12:11 AM, Brett Cannon <brett@python.org> wrote:
On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg <mal@egenix.com> 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
On 16.03.2017 00:49, Brett Cannon wrote:
On Wed, 15 Mar 2017 at 08:44 Berker Peksağ <berker.peksag@gmail.com> wrote:
On Mon, Mar 13, 2017 at 12:11 AM, Brett Cannon <brett@python.org> wrote:
On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg <mal@egenix.com> 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/
On Mar 10, 2017, at 2:13 PM, Brett Cannon <brett@python.org> 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
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. <wink>
On Sun, 12 Mar 2017 at 19:11 Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Mar 10, 2017, at 2:13 PM, Brett Cannon <brett@python.org> 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
On Mar 14, 2017, at 18:05, Brett Cannon <brett@python.org> 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 nad@python.org -- []
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
On Mar 14, 2017, at 19:25, Barry Warsaw <barry@python.org> 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 nad@python.org -- []
On Tue, 14 Mar 2017 at 16:26 Barry Warsaw <barry@python.org> 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.
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
On Wed, 15 Mar 2017 at 17:03 Barry Warsaw <barry@python.org> 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?
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
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 <barry@python.org> 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/
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 <http://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/
On Mon, 13 Mar 2017 12:48:30 -0400, Yury Selivanov <yselivanov.ml@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 :(
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
On Mon, 13 Mar 2017 at 12:36 R. David Murray <rdmurray@bitdance.com> wrote:
On Mon, 13 Mar 2017 12:48:30 -0400, Yury Selivanov < yselivanov.ml@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.
On Mon, 13 Mar 2017 at 09:48 Yury Selivanov <yselivanov.ml@gmail.com> 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 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 <http://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/
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!
On Wed, 15 Mar 2017 22:56:33 -0400, Yury Selivanov <yselivanov.ml@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 :)
--David
On Wed, 15 Mar 2017 at 20:24 R. David Murray <rdmurray@bitdance.com> wrote:
On Wed, 15 Mar 2017 22:56:33 -0400, Yury Selivanov < yselivanov.ml@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.
On 2017-03-16 12:16 PM, Brett Cannon wrote:
On Wed, 15 Mar 2017 at 20:24 R. David Murray <rdmurray@bitdance.com <mailto:rdmurray@bitdance.com>> wrote:
On Wed, 15 Mar 2017 22:56:33 -0400, Yury Selivanov <yselivanov.ml@gmail.com <mailto:yselivanov.ml@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.
I just discovered this handy tool: https://github.com/github/hub. Will try to use it and will share my experience.
Yury
On Mar 10, 2017, at 5:13 PM, Brett Cannon <brett@python.org> wrote:
Is the mention bot helpful? (Our config is at https://github.com/python/cpython/blob/master/.mention-bot <https://github.com/python/cpython/blob/master/.mention-bot> and the docs are at https://github.com/facebook/mention-bot <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
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.
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.
On Fri, 24 Mar 2017 14:29:13 +0100, Antoine Pitrou <antoine@python.org> 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
Hi,
Le 24/03/2017 à 16:11, R. David Murray a écrit :
On Fri, 24 Mar 2017 14:29:13 +0100, Antoine Pitrou <antoine@python.org> 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?
Apologies for being slightly imprecise. Yes, "git fetch origin 3.5" actually fetches the remote changes, but it doesn't update the local "3.5" branch with those changes, so when I do "git diff 3.5" from another branch, I get spurious changes in the diff.
(perhaps I should do "git diff origin/3.5" instead?)
Regards
Antoine.
On Sat, Mar 25, 2017 at 12:22 AM, Antoine Pitrou <antoine@python.org> wrote:
Hi,
Le 24/03/2017 à 16:11, R. David Murray a écrit :
On Fri, 24 Mar 2017 14:29:13 +0100, Antoine Pitrou <antoine@python.org> 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?
Apologies for being slightly imprecise. Yes, "git fetch origin 3.5" actually fetches the remote changes, but it doesn't update the local "3.5" branch with those changes, so when I do "git diff 3.5" from another branch, I get spurious changes in the diff.
(perhaps I should do "git diff origin/3.5" instead?)
Regards
Antoine.
Yes, git diff origin/3.5 is normal way. If you always use feature branch,
there are no need for local 3.5 branch.
I usually create "backport" branch by: git checkout -b backport-xxx-35 origin/3.5.
OTOH, there is hackey way. Assuming you didn't have checkout of local
3.5 branch,
git push . origin/3.5:3.5 may update 3.5 branch.
On Fri, 24 Mar 2017 at 06:26 Antoine Pitrou <antoine@python.org> 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).
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.
participants (18)
-
Alex Gaynor -
Antoine Pitrou -
Barry Warsaw -
Berker Peksağ -
Brett Cannon -
Donald Stufft -
Ezio Melotti -
INADA Naoki -
M.-A. Lemburg -
Mariatta Wijaya -
Martin Panter -
Ned Deily -
Nick Coghlan -
Paul Moore -
R. David Murray -
Raymond Hettinger -
Yury Selivanov -
Zachary Ware