[Python-Dev] Burning down the backlog.

[Paul Moore]

On 25 July 2015 at 20:28, Robert Collins <robertc at robertcollins.net> wrote:
> Those charts doesn't show patches in 'commit-review' -
> http://bugs.python.org/issue?%40columns=title&%40columns=id&stage=5&%40columns=activity&%40sort=activity&status=1&%40columns=status&%40pagesize=50&%40startwith=0&%40sortdir=on&%40action=search
>
> There are only 45 of those patches.
>
> AIUI - and I'm very new to core here - anyone in triagers can get
> patches up to commit-review status.
>
> I think we should set a goal to keep inventory low here - e.g. review
> and either bounce back to patch review, or commit, in less than a
> month. Now - a month isn't super low, but we have lots of stuff
> greater than a month.

I'm not actually clear what "Commit Review" status means. I did do a
quick check of the dev guide, and couldn't come up with anything, but
looking at the first issue on that list
(http://bugs.python.org/issue24585) the change has been committed but
it can't practically be tested until it's released in a beta. The
second on the list also seems to have been committed.

While post-commit reviews are useful, I wouldn't classify not getting
them as a pressing problem (after all, the change is in, so in the
worst case we'll get bug reports if there *were* any issues). Getting
patches to a state where they can be committed, and more importantly
actually committing them, is the bigger problem.

Looking at "Issues with patches" for example, I find
http://bugs.python.org/issue21279. That is a simple doc patch, and
there's a pretty lengthy discussion on getting the exact wording right
(plus six revisions of the patch). That seems excessive, but
nevertheless...

My problem is that in order to commit that patch (which seems to be
the next step - I see no reason not to) I'd need to go through working
out all of the commit/merge process, and make sure I got it all right.
That's a lot of work (and some level of risk) - particularly compared
to working on pip, where I hit the "merge" button, and I'm done. So
that patch languishes until someone other than me, who's more familiar
with the commit process, merges it.

Of course, I could learn the patch process, but my time for working on
tracker items is limited, and my brain is getting old, so the
likelihood is that I'll forget some of the details before next time,
so that learning time isn't a one-off cost.

This is basically what the improved dev workflow peps are about, so
people are working on a solution, but to me that's the big problem -
we need a big red "Commit" button that provides a zero-effort means
for a core dev to point at a patch on the tracker that's already been
fully reviewed, and just say "do it". Personally, if I were actually
expecting to do enough commits to justify the effort, I'd write a
script to do that (and I'd probably isolate my build environment in a
VM, somehow, as I rebuild my main PC often enough that even having a
build env present on my PC isn't a given).

Paul