On 25 July 2015 at 20:28, Robert Collins <robe...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com