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> _______________________________________________ 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/