Shouldn't this be on general@ ? More inline.
On 1/27/02 10:03 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > 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. +1 > 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. How about suggest that each project add a 'jakarta-site' target to the build script. Then, Gump can build that if it finds it, and if not there, ignore. So a project can then put in jakarta-site when things are groovy and automated is fine, and take it out when it wants to take control back for whatever reason. > > 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! Could we have a magic file (say xdocs/yo_sam_now_would_be_a_good_time for those projects that follow the xdocs/ pattern...) that when committed via CVS triggers the build/rsynch? Then CVS write permissions are the gating factor for site update (which is wholly appropos...) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting "Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech." - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
