core-workflow April 2017

core-workflow@python.org

13 participants
6 discussions

What do people want Bedevere to do for issue numbers in PRs?

by Brett Cannon

When I implemented Bedevere's bpo issue number detection it was to do it as a status check as I thought that's what people wanted ( https://github.com/python/core-workflow/issues/13). But now others are saying they want a comment with a link to the issue number ( https://github.com/python/bedevere/issues/3). So which one(s)? :) The status check has the perk of being very visible so that people know it's missing (arguably if you don't check your PR you won't notice the failure, but if you're not checking the status of the PR then there are other problems to attend to). The drawback is that you have to know that the Details link for a successful check links to bugs.python.org and that once the PR is closed the link is gone. The perk of a comment is it's in your face and easy to find. The drawback of a comment is you always be notified about the comment which might get tiresome. So what I'm asking is what do people want? The status check? A comment? Both? I know people want *something* since dealing with specifying the issue number has been coming up consistently since we started the new workflow, but at this point I want a clear understanding of what people want so this can be settled appropriately.

4 years, 7 months

Re: [core-workflow] Voting on possible subdomains for the devguide

by Eric Holscher

I'm not subbed to this list, so clicked the link from the web UI, which contains no history/quotes. Sorry! Just a few points: * We provide search that is backed by Elastic Search, which provides a lot more power. We also have more customizations that will allow us to provide search across projects within the python docs search, if wanted. So you could also return PEP's, devguide, and other search results if that was useful. * Any improvements that we made to RTD in order to better support Python would also be shared with the Python ecosystem. So instead of spending time writing build scripts and services, we could be contributing to an existing project that is widely used in the community. This would hopefully help us increase developer contributions to Read the Docs, raising all boats in the community. * We run on nginx servers, so we can do custom rules for Python if necessary. This is really useful for things like redirects and custom headers. * We automatically generate PDF's, Epub's, and JSON HTML versions of the docs, which I don't believe is currently happening. * We have lots of other things that are nice features (http://docs.readthedocs.io/en/latest/features.html), which static file hosting won't have, and the site is still under active development. We have servers running behind the code, and in the future plan to extend things like intersphinx to be much more powerful, using server based software. Sphinx itself is always limited in it's design by being a static site, and we remove that requirement (in a way that is generally additive, so it downgrades to Sphinx). I would also say that we'd hope the PSF would help fund the site in an ongoing manner under this arrangement. The PSF has given us grants in the past for our support of the Python ecosystem, and this would just cement that relationship even more. By hosting on RTD and supporting us financially, you'd also be helping support the entire ecosystem. That said, it isn't a prerequisite for migrating to RTD, but I think it would make a strong case for sustained funding. Cheers, Eric -- Eric Holscher Maker of the internet residing in Portland, Oregon http://ericholscher.com

4 years, 8 months

Voting on possible subdomains for the devguide

by Brett Cannon

With part of the goal of moving to GitHub being to minimize how much infrastructure we have to run, one of the long-term goals I have is to use Read the Docs to host Python's documentation. But to get there we have to move any "special" docs over first. That means relocating the devguide (it also means relocating the PEPs, but that's another issue and is blocked first and foremost by https://github.com/python/peps/issues/4). Thanks to the work of various people we have https://cpython-devguide.readthedocs.io/ so the toolchain for building the devguide on RTFD is done. That means the next step is deciding on a subdomain on the python.org domain to host the docs from. If you have an opinion, go to https://github.com/python/core-workflow/issues/4 and leave a reaction on the appropriate message.

4 years, 8 months

Please disable CLA checking for trivial GitHub patches

by Alex Jordan

Heya! Recently I sent https://github.com/python/cpython/pull/1012 - a typo fix to the docs. I got prompted to sign the CLA, but as I described in https://github.com/python/cpython/pull/1012#issuecomment-292038637, I really think that was unnecessary since it was only a couple characters. The bot should probably be adjusted so it doesn't prompt for casual drive-by contributions. I'm not subscribed so I won't see replies, but feel free to CC me if you need to (can't imagine why, though). Cheers! AJ

4 years, 8 months

I have created https://github.com/python/bedevere

by Brett Cannon

The Heroku instance is set up, but I have not turned it on for the CPython repo yet as I'm sick and that just means I will mess up any debugging I may need to do if something goes wrong. :) So once I'm well I will turn it on (the way I'm feeling, probably not until the latter half of next week :( ).

4 years, 8 months

Starting a bot to identify issues with PRs

by Brett Cannon

I have created a bot that I hope we can use to host all non-CLA checks for a PR that isn't covered by CI: https://github.com/brettcannon/bedevere. To start, the bot would check for a bugs.python.org issue number and set a failing status if one isn't found, else link the status to the issue itself. If the approach I took in the bot seems reasonable to people I will add support for a "trivial" label which would cause the bot to say the check is successful due to the fact that the PR is trivial enough to not warrant an issue to begin with. We can then continue to expand this bot to do other things like check that there is a NEWS file (unless marked as "trivial"). I don't want to role the CLA bot into bedevere since I created the bot in such a way as to be useful to other organizations on GitHub. So the Knights Who Say Ni will stay a separate repo.

4 years, 8 months

2021

2020

2019

2018

2017

2016

2015

2014

core-workflow April 2017