Roundup Tracker - Issues

Message4655

Author kai
Recipients jerrykan, kai
Date 2012-10-09.22:09:53
Message-id <5074A0A9.1080501@xs4all.nl>
In-reply-to <1348998193.9.0.507109539339.issue2550774@psf.upfronthosting.co.za>
Hi John,

John Kristensen wrote:
> John Kristensen added the comment:
> 
> Hello Kai,

Thanks for getting back on this.

> The first part of the patch (regenerate the html version of the docs)
> looks good to me. It looks like the rst2html stuff is no longer
> relevant, so removing the Makefile and updating the README.txt makes
> sense. I would be happy to commit that part of the patch as it is, but I
> will wait a few more days to see if anyone else has anything to add.

Good.

> I think the part to do with the 'website/www' is a good start, but might
> need a bit more work before committing the changes:
> 
>  - Creating a symlink for 'COPYING.txt' makes the error go away, but the
> link in 'license.txt' to 'COPYING.txt' doesn't actually show up in the
> generated html (so this should probably be fixed as well).

Ah. But thats part of the documentation, not the website. The docs get
"symlinked" into the website. You will encounter a link to the license
from the subdir 'doc/index.html'.

>  - I'm not sure if the 'COPYING.txt' file was intended to be processed
> by Sphinx, so it might be worth seeing if 'make' can skip processing the
> file but still link to it as a plain text file.

See previous comment; Its there because license.txt includes it.

>  - During the 'make clean' command, if we are leaving the 'html/'
> directory in place then we probably want to leave the 'COPYING.txt' file
> in place as well; seeing as though it will be linked too (ie. delete
> only the intermediate files). Alternatively if we want to remove the
> 'COPYING.txt' file we should also remove the 'html/' directory (ie.
> delete all generated files). I'm not sure which is the convention for
> 'make clean' (delete all generated files or just intermediate files)

Good point. I'll fix the clean target to remove $(HTML) too.

> On a semi-related note, personally I would also split this up into two
> separate patches/issues (ie. one patch/commit per fix). This isn't
> necessarily a convention of the project, but I find much easier to
> review small concise patches, and I'm more likely to commit changes if
> it doesn't take a lot of effort on my part :D

I can see your point. My fix is the fastest way to get it working again.
I'll be crafting a shorter commit soon.

Cheers,
Kai
History
Date User Action Args
2012-10-09 22:09:55kaisetrecipients: + kai, jerrykan
2012-10-09 22:09:55kailinkissue2550774 messages
2012-10-09 22:09:53kaicreate