hi sam On Sunday, January 27, 2002, at 03:03 PM, Sam Ruby 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. i think that the only reason i use the account on daedalus (i'm right in thinking that the cvs login uses another machine, aren't i?) is to update sub-project web sites. doing these updates makes me nervous and i'd gladly give up my account if there was another way of doing them. > 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 i'd be happy for anyone who can't play by the rules to lose access rights to daedalus. is there any way that the conflict could be recognized and a warning posted somewhere so that the problem can be fixed as quickly as possible? > 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. +1 > 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. +1 > 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! i quite like the idea of scheduled updates. with the main site we seem to be moving towards posting up changes so that people get a chance to improve them before they go live. i think that this some merit for sub projects as well. your plan sounds like a good one to me :) - robert -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
