commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dion <>
Subject Re: [PLAN] Updating sub-project web pages
Date Sun, 27 Jan 2002 21:08:44 GMT
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 

>> 2) Gump already builds the site and captures jars and javadocs.  See
>> and
>> .  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
>> 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 

>> 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

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message