For security and performance reasons, builds of web pages are not to be done on daedalus (the machine that hosts Apache's web presence). Also for security reasons, new accounts are not automatically being created on daedalus. In fact, Brian has indicated that he ultimately wants to reduce the number of accounts on daedalus.
Here's how I would like to incrementally address the issue: 1) I'll create a cron job to do a cvs update of the jakarta site several times a day. I will expand it to include other subprojects on request. While I may adjust the frequency with which this job runs, I expect to run at least once a day Ramifications of this: first the existence of this job does not preclude manual updates out of cycle by those with access to do so. What it does mean, however, is that if someone goes and directly updates the web site (which despite all the warnings, does happen from time to time), this will inevitably result in a merge conflict and need to be manually resolved. 2) Gump already builds the site and captures jars and javadocs. See http://gump.covalent.net/jars/ and http://nagoya.apache.org/~rubys/gump/javadoc.html . I'll add logic to capture sites and publish them separately (i.e., not on the main site). Subprojects who want to participate need only ensure that the target that gump is building for them does cause the site to be built, and then need to identify the directory into which this site is placed. I anticipate that this will be done in a quite similar manner to the way that javadocs are done; see http://jakarta.apache.org/gump/project.html#javadoc for details. For those who wish to get involved, please click on any of the get involved links on the left hand side of the page. 3) Once that is stable, I plan to convert the cron job on a subproject to subproject basis from a cvs update to using rsync. This means that the generated html will no longer need to be checked into cvs. It also addresses the problem identified in #1 above. I expect the rsync process to occur more frequently than the cvs update as it consumes less resources, but I expect the builds to be done less frequently. I still expect the minimum frequency to be once a day. 4) Ultimately, I'd like to explore means of allowing this process to be triggered by other means; either on demand or by virtue of the cvs commits themselves. Any suggestions along these lines would be appreciated - once again, feel free to get involved! - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
