On Wed, Feb 22, 2017 at 4:22 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 18 February 2017 at 09:24, Donald Stufft <don...@stufft.io> wrote: > > We turned on require code review for the PR, though at the time I > *thought* > > it still allowed you to approve your own PR. Apparently that was wrong. > > Brett was the one to actually make the decision to do it and turned it > on, > > so I don’t know if he knew that it didn’t allow people to self-approve or > > not. The impetus to do this was to make sure that all changes went > through > > the PR process and folks didn’t directly push to `master`. > > While this is a good ideal to strive for, I'm starting to think it > isn't practical with our current development set up. > > The trigger for this change in my thinking was going to merge > https://github.com/python/cpython/pull/171 which is basically fine, > but needs a few clean-ups prior to committing: > > - Misc/ACKS update > - Misc/NEWS entry > - What's New entry > - (and probably a rebase due to Misc/NEWS) > > It's generally easier to just add those myself rather than asking the > contributor to do it, and then the contributor can look at the final > commit to see what these additional bookkeeping entries look like. > > However, without the ability to commit locally and then push to GitHub > from there, you end up with one of two options: > > - attempt to amend the original PR (see > https://github.com/python/devguide/issues/129 ). That may not work > depending on how the contributor has set up their fork and PR branch. > - create a new PR and close the original one (with the corresponding > subpar experience for the original contributor) > You should be able to cherry-pick his commit. For that it's worth setting your repo to be able to checkout any PR submitted to a repo: https://gist.github.com/piscisaureus/3342247 with that you can basically do git checkout pr/XXX and from that you can easily get the commit id and be able to cherry-pick it, amend it or add new thing on top of it. In the end submitting a new PR, replacing the original one. > > So as much as I'd like to keep it, it probably makes sense to turn off > branch protection for now and instead start making a list of the > things that would be needed to turn it back on, starting with: > > - a way of reliably editing PRs that doesn't require closing them and > creating new ones > - conflict-free NEWS entry definition > - a way for core developers to handle minor changes autonomously > rather than always needing someone else to be online and responsive > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > 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 >
_______________________________________________ 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
