[Python-Dev] 2.3.6 for the unicode buffer overrun

Anthony Baxter anthony at interlink.com.au
Fri Oct 13 07:05:22 CEST 2006

On Friday 13 October 2006 12:56, Steve Holden wrote:
> The real problem is the more or less complete lack of incremental
> rebuild, which does make site generation time-consuming.

That's _part_ of it. There's other issues. For instance, there's probably 4 
places where the "list of releases" is stored. Every time I do a release, I 
need to update all of these. If it's a new release, I also have to update the
apache config for the /X.Y.Z redirect (anyone who thinks a default URL of 
www.python.org/download/releases/X.Y.Z is a good idea needs to quit drinking
before lunchtime <wink>)

Creating a new release area, or hell, even a new page, is a whole pile of 
fiddly files. These still don't make sense to me - I end up copying an 
existing page each time, then reading through them looking for the relevant 
pieces of text. Personally, I can mostly deal with the reST now, although it 
still trips me up on a regular basis. YAML as well is just way more 
complexity - I don't understand the syntax, but it appears to offer massively 
more than we actually use.

> The advantage of pyramid implementation was the regularisation of the
> site data.

Sure - and hopefully if we go down another path we can get that out.

> To retain the advantages of source control this might mean using scripts
> to generate database content from SVN-controlled data files. Or
> something [waves hands vaguely and steps back hopefully].

The other thing to watch out for is that I (or whoever) can still do local 
work on a bunch of different files, then check it in all in one hit once it's 
done and checked. This was an issue I had with the various wiki-based 
proposals, I haven't seen many wikis that allow this.

Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.

More information about the Python-Dev mailing list