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 (
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
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.
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
* 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.
Maker of the internet residing in Portland, Oregon
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.
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 :( ).
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.