On Wed, 2 Dec 2015 at 03:42 Berker Peksağ <berker.pek...@gmail.com> wrote:
> On Wed, Dec 2, 2015 at 1:24 AM, Brett Cannon <br...@python.org> wrote: > > It's Dec 1, which means it's time for any questions people have about the > > proposed workflows so we can get answers by Dec 15. > > > > I have one question that applies to both proposals and one specific to > > GitLab. The general one is whether both Guido and me can both be happy. > :) > > Guido doesn't want intermediate commits nor what he calls "merge turds" > to > > show up in the history. I want to be able to do merges from the browser. > Do > > I agree with Guido. --no-ff merge is probably the only GitHub feature > that I really dislike. It would be good to have a GitHub bot to handle > ff merges. > > For example, with a bot, a core developer can add one of the following > comments to merge the PR; > > @biggles merge # merges into master > > @biggles merge 3.5+ # merges into 3.5 and master (or merges into > master then cherry-pick it to 3.5) > > This will also solve the pull request and email flood problem since a > contributor won't have to open N pull requests if their patch needs to > be backported to maintenance branches. > I was actually wondering if this was possible just last night. :) Do both GitHub and GitLab have the appropriate APIs to support something like this? It would be fantastic if a bot can get Guido the style of commits he wants while letting us trigger the merges through the browser (especially since a bot is nice, but we don't have to feel like we are stranded if it goes down since old-school solution of manual merges would still be possible). And could the bot, when told to cherry-pick/merge into another branch, create a PR if there is a merge conflict so that it can be fixed in a checkout and not lost track of? Otherwise at least leave a message in the PR that stated what versions to commit to that failed and hence not close the PR until all branches are properly handled? And this bot doesn't have to do it, but we should definitely make sure we have at least automated testing of all PRs on *some* OS and also a way to verify the PR contributor signed the CLA (the testing should be easy enough on either and the CLA should be doable somehow). > > I will have some spare time to work on such a tool in the next months. > Great! Let's choose the platform first -- I'm aiming for Jan 1 -- and then if you still have time, Berker, it would be great if you can help with the tool. But we can definitely discuss potential workflows and what the bot would need to do now since that's probably platform-agnostic to make sure this is a tenable solution.
_______________________________________________ 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
