> > On Feb 18, 2017, at 4:38 PM, Steve Dower <steve.do...@python.org> wrote: > > (I'm not subscribed to this list, so please keep me on CC) > > Was there any discussion about allowing core developers to bypass any of the > PR checks? Or was there an assumption that we'd just push directly to the > main repo?
See: https://mail.python.org/pipermail/core-workflow/2017-February/000884.html <https://mail.python.org/pipermail/core-workflow/2017-February/000884.html> > > For example, most of my contributions are to do with the Windows installer. > Due to the nature of installers, virtually nobody else is confident to review > anything complex, or even simple ones (such as > https://github.com/python/cpython/pull/160) due to not being able to predict > the flow on effects. As a result, I make many small changes that would take a > long time to get reviewed. So as I said to Barry in the linked thread, part of the goal here is to force the process between committers and non-committers to be as similar as possible which will solve the real very real problem (that the GH migration’s goal was to help with) that when you have two processes, a stream lined one for those in power and a bulky slow one for those not, that it is hard to get the bulky slow once fixed because nobody in power ever experiences it. By aligning the two processes as much as possible, we identify pain points are forced to solve them or deal with them. This sounds like one such problem. If you’re the only person capable (for skill or confidence) of reviewing these changes, what happens if you’re unavailable for some reason? (Burnout, illness, whatever). Is there any effort to mentor or attract additional contributors who are able to review these changes? I’m guessing there is not, and the risk to allowing bypassing the requirement is that there never *is* a plan to fix it. On the other hand, much like I said with Barry, it’s also possible that these problems are special enough that we can or should just relax restrictions in order to allow forward movement to still happen. > > Similarly, many of my changes are not touched by the automated builds. > Particularly anything to do with the installer is certainly not going to be > built on a Linux box, and most (probably all) Windows buildbots don't build > the installer right now. I've seen some systems where tags can be applied to > a PR to skip build validation - I would certainly find that valuable. This also sounds like a problem to me :) Obviously not the Linux part (but then, burning some CPU on running the test suite on Linux isn’t really that big of a deal is it?), but probably the installer should be getting tested in some way? > > But essentially, I believe it should be within the power of core developers > to bypass the checkin requirements (review + builds) and force a merge. > Currently this is not possible - could it be enabled? Obviously it's placing > trust in our core dev team, but that's the way it has always been, and we > don't lose any traceability from this (unlike allowing people to delete > branches from the repo, which can permanently lose code). I mentioned it above, but to my mind (and this is just a personal opinion) it’s not really anything about *trust*. If we have two different processes, we are going to make the one that we, the people in power, use be as streamlined as possible and the other process for non committers will *likely* end up slowly bitrotting and not keeping up with no tooling, changes, and ideas that can make it better. Forcing everyone onto the same process means that as we figure out and continuously improve the process for us, it also improves it for other people who do not have a commit bit. — Donald Stufft
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
