* Andr? Malo ([EMAIL PROTECTED]) wrote : > Not so long time ago the build process wasn't stable enough (produced > different results in different environments). After some tricks to work > around the problems we could consider this point resolved now. > OK, so this sounds like a reasonable thing to do now.
> The last important thing for me is: We lose control. For example, when > committing changes in Korean or Japanese I treat them as opaque binary data > and handle them very carefully (double checking the diffs before the > commit). Well, this is true. But if the data we have in the xml docs is incorrect then we're in trouble anyway, no? (And, similarily, if the transform doesn't work correctly we're equally in trouble) > If we drop the html files from CVS we need more eyes on the online docs and > more docco eyes on (pre-)releases. And of course, tons of java code > installed on every system that builds from CVS. (need to mention that > somewhere in /dev/?) > Well, having more eyes sounds like a win rather than a problem, to be honest. The requirements for the building the docs would definitely need to be better documented - it took me quite a while to find out how to build the docs when I was doing my changes to htpasswd recently. > Said that, I'm trusting the build system now and give a +-0 on dropping the > generated files - except the generated manpages (these would change their > last-modification-data everytime otherwise). > Hrm, can't we base last-modification-date off the cvs $Id$ string? -Thom
