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.
[*] If someone knows a Mailman developer, it might be nice to request some plugin to do custom Subject mangling. <wink>