[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