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

[Barry Warsaw]

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

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

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

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

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

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

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

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

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

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

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

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

Cheers,
-Barry

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