robert burrell donkin wrote: > 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.
Let's go the automated way - it makes everyone's job easier. > >> 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 > Sounds great. >> >> 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? Emails, like the current build failures would be good, but even better, is there a way to 'roll out' of a checkout that would cause a merge conflict? >> 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. > So does this mean we should start by discussing it on alexandria-dev? > > +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 I dunno about this one. I'd much prefer that the docs be committed to cvs, that way there's always a way back if someone screws up the documentation. >> 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! > CVS commits would be my preferred solution. Only build the docs when they change, rather than wasting cycles/time each night on a whole heap of stuff that doesn't change. > 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 :) > ditto....see u in alexandria-dev? -- dIon Gillard, Multitask Consulting http://www.multitask.com.au/developers -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
