You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Sam Ruby <ru...@us.ibm.com> on 2002/01/27 16:03:15 UTC
[PLAN] Updating sub-project web pages
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PLAN] Updating sub-project web pages
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Shouldn't this be on general@ ?
More inline.
On 1/27/02 10:03 AM, "Sam Ruby" <ru...@us.ibm.com> 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. geirm@optonline.net
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PLAN] Updating sub-project web pages
Posted by robert burrell donkin <ro...@mac.com>.
On Sunday, January 27, 2002, at 08:30 PM, Peter Donald wrote:
> On Mon, 28 Jan 2002 06:08, robert burrell donkin 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.
>
> You will still need it to upload releases - until Sam gets around to
> removing
> that need ;)
i'm very happy leaving releases to my elders-and-betters (as they say) :)
>>> 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.
>
> errr... don't think that has anything to do with it.
it quite possibly hasn't - but let me expand...
let's say somebody edits a web site file which is in cvs and introduces a
(potential) conflict. later the cron script runs and cvs tries to merge
but finds and marks the conflict. oops - now we've got live pages which
are no longer valid html.
is this a good reason to reject automatic updates? i'd say - no. if
somebody can't be trusted to avoid this problem then they probably can't
be trusted to access daedalus.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PLAN] Updating sub-project web pages
Posted by Peter Donald <pe...@apache.org>.
On Mon, 28 Jan 2002 06:08, robert burrell donkin 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.
You will still need it to upload releases - until Sam gets around to removing
that need ;)
> > 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.
errr... don't think that has anything to do with it.
--
Cheers,
Pete
*-----------------------------------------------------------------------*
PROGRAM: n. a magic spell cast over a computer allowing it to turn
one's input into error messages. v.t. to engage in a pastime similar
to banging one's head against a wall, but with fewer opportunities for
reward.
*-----------------------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PLAN] Updating sub-project web pages
Posted by dion <di...@multitask.com.au>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PLAN] Updating sub-project web pages
Posted by robert burrell donkin <ro...@mac.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>