Hi -- I've recently added some documentation to the LLVM docs subdirectory, and was wondering about a couple of things:
- How should I best debug whether the docs (in RST) are syntactically correct? Are there recommended practices for doing a sanity check on the docs?
- How often do the documents get built and uploaded to the website?
Thanks – interesting that the docs haven’t been updated since March 15th:
Yes, this happens when the server’s sphinx installation picked up on
something that neither your installation or the buildbot’s did.
I’ll have a look if I can untangle that.
Thanks Renato!
cheers,
–renato
PS: We really need a better way of doing this…
Has anybody looked into potentially getting the LLVM docs hosted on readthedocs.org and automatically built from the LLVM Git mirror (or through Subversion post-commit hooks)? Since we’re already using Sphinx, this seems like a low-cost, low-interference way of hosting the generated documentation.
Well, that didn't last long. Now I remember why last time I fixed
hundreds of warnings on the docs directly instead of fixing the
server...
Has anybody looked into potentially getting the LLVM docs hosted on
readthedocs.org and automatically built from the LLVM Git mirror (or through
Subversion post-commit hooks)? Since we're already using Sphinx, this seems
like a low-cost, low-interference way of hosting the generated
documentation.
This is actually a very good idea. I'll let Tanya and Anton further
comment on that from a foundation's point of view.
Well, that didn't last long. Now I remember why last time I fixed
hundreds of warnings on the docs directly instead of fixing the
server...
Has anybody looked into potentially getting the LLVM docs hosted on
readthedocs.org and automatically built from the LLVM Git mirror (or through
Subversion post-commit hooks)? Since we're already using Sphinx, this seems
like a low-cost, low-interference way of hosting the generated
documentation.
This is actually a very good idea. I'll let Tanya and Anton further
comment on that from a foundation's point of view.
The docs are built via SVN post-commit hook, but thats not the bigger issue in my opinion. I don’t know enough about readthedocs.org but if someone has a lot of experience.. perhaps they could summarize pros and cons of using it?
I’m not opposed to change just need to understand it. I’m actually going to be handing off most of this stuff as soon as I can write the email to the list (sorry its Spring Break here in the US so my time is limited this week). I have someone who is going to help with sys admin on llvm.org and head things up in that area but ideally its a team of people.
I don't know enough about the website, but there are other problems in
our infrastructure:
* We need to manually update Sphinx. People out there can have much
newer versions, which accept newer syntax, and it doesn't break on
their side, but it breaks on the server.
* We have buildbots that validate the docs, but again, it's a
completely separate machine, with a different version still (at least
potentially).
* The buildbot doesn't push its builds to the server, nor it's
guaranteed to have the same version as the actual builder, so
maintenance is hard.
* The server process doesn't warn people when it breaks. At least not
developers.
What does this website fix?
* Can it report failed builds? Or at least show on a public webpage
what's the problem?
* Can we email people when the docs are broken? At least a generic
list like llvm-admin?
* How often Sphinx is updated on the website? Is it always the most
modern version?
I think those three points are true, but I don't know for sure. If
they are, at least some of the problems are fixed.
Another solution is to make the buildbot push the docs somewhere, so
at least we have a consistent process, and whatever happens on the
public bot, happens on the docs.
But that seems more involved and problematic (SSH/FTP keys, etc.),
which may defeat our "move to public infrastructure to avoid costs"
trend.
In that sense, this website is somewhat similar to hosting our code on
GitHub. It's someone else's problem.