On 15 December 2015 at 07:46, R. David Murray <rdmur...@bitdance.com> wrote: > That said, we really don't want the bot to have only a single > maintainer, though it may initially have a single author, and ideally > operations would be responsible for keeping it running.
There are a number of existing Python projects that provide the scaffolding for handling GitHub webhook requests (e.g. https://github.com/nickfrostatx/flask-hookserver is a project for setting up a GitHub bot as a Flask web service), so getting something up and running on Heroku should be relatively straightforward (Donald has been looking at PaaS hosting options of late, and a GitHub bot wouldn't benefit from a full VM in the Rackspace infrastructure). > There are a number of advantages to having a bot be the way this works > rather than depending on features of the provider's software, easier > integration with other tools (ie: the tracker) being a big one. > It would also presumably make switching providers somewhat easier. Right, GitLab offers its own webhook support (although I assume the event details are different), so going with a bot-based workflow even means that we could even offer a read-write GitLab mirror in the future, since the bot would handle the actual merge-and-commit process based on review comments, regardless of which server was used to submit the review. 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
