I wasn't asking for more precision than daily (I just hadn't seen it), but now that I think about it it would indeed be nice to know when the cron job starts, so that we know that if the checkin didn't happen before then, it won't show up in the online docs until the next day. I don't think this is particularly *important* to know, it would just be nice to know.
That's different from asking that it be documented, though. I don't mind you knowing (it's at 15:00 local time for the build machine, which sits in the Europe/Amsterdam timezone). Just ask specific questions, and people may give specific answers. Now that you know, I still don't think it needs to be documented (else: where would that end? Would you want to know account name and uid of the build also, and the partition of the hard disk where the files are stored? Not even I know the rack slot in which the machine sits).
Is it only the development versions that get updated, or do our updates to the next bug fix release also get posted daily (and those are the docs web site visitors normally see, I believe)?
That's what the documentation claims, yes. The build script currently has these targets:
BRANCHES = [ # checkout, target, isdev (BUILDROOT + '/python26', WWWROOT, False), (BUILDROOT + '/python31', WWWROOT + '/py3k', False), (BUILDROOT + '/python27', WWWROOT + '/dev', True), (BUILDROOT + '/python32', WWWROOT + '/dev/py3k', True), ]
To answer your question about what wording I'd like, I think that it would be worthwhile to say somewhere (not necessarily on that page...maybe in the doc README.txt?...but it could be ont that page...) that the docs are auto-built by a cron job on the server hosting docs.python.org running 'make dist' in the doc directory of a freshly updated checkout and then....doing something with the resulting files?
Actually, the command is rather like this:
'cd Doc; make autobuild-%s' % (isdev and 'dev' or 'stable')
Background: one of my tasks for one of my customers is helping them try to make it so that an outsider coming in could learn everything they needed to know to operate the system from the available docs...a goal that they are nowhere near achieving, but which I think is a worthwhile goal for which to strive.
For this kind of work, I think looking at the actual installation is more productive to learn how things are done (perhaps opposed to how they were originally planned to be done). I didn't know how this all worked myself, either, but, using the root account, it took me only a minute to find out - much faster than finding the documentation that may have explained it in detail.
The only starting point that you need is the machine that you know it runs on.