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 <[EMAIL PROTECTED]> It's never too late to have a happy childhood. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
