"Noel J. Bergman" <[EMAIL PROTECTED]> wrote on 19/11/2003 04:52:48 AM:
> Noel wrote: > > As far as I know, all sites are supposed to be in CVS, and checked out > into > > the file system. Amongst the reasons for this are to ensure that > > infrastructure can recover them rapidly in the event of a problem. This > > includes sites generated by Forrest or Maven. > > Martin Cooper wrote: > > This makes a great deal of sense. Unfortunately, as far as I'm aware, none > > of the Maven generated sites are checked in. That's probably because Maven > > does so much (e.g. site:deploy) that it doesn't occur to people (including > > myself) to take the extra step and check in the generated site. > > > > I'm not aware of an actual policy that requires this, but it wouldn't be a > > bad idea. Perhaps I'll bring that up on [EMAIL PROTECTED] In the meantime, > > it would be a good policy for us to introduce to Commons, at least, while > > we're in the process of sorting out our own web site infrastructure. > > Dion Gillard asked: > > Is this a definite rule? > > Is there somewhere it's mandated? > > I'm asking as I don't remember it being required. > > It is part of the "official" documentation maintained in the Apache site > module by the infrastructure team: > > - Every project also has a "proj-www" module that corresponds > to the public website specific to that project. This module > appears when one goes to the web site "http://proj.apache.org";. > ref: http://www.apache.org/dev/svc-name-template.html Yep, I've seen this before, but it doesn't seem to be used in practice. > - All CVS modules are in the form "$project[-$codebase]", > where $codebase is an optional extension for subclassing > the project into a couple separate parts. Decide which > CVS modules you want to create. There should be at least > one for the web site, "$project-site". > > Create /www/$project.apache.org directory, chmod g+w, > chgrp'd to $project. Do a "cvs checkout $project-site" > into that directory > ref: http://www.apache.org/dev/project-creation.html > > - The websites are served from directories under /www on > daedalus. But you usually do not edit any content in those > directories. Each website is an anonymous CVS checkout of a > repository on icarus. > ref: http://www.apache.org/dev/committers.html#web > > That last one goes into more detail. > > Obviously, the documentation needs a bit of tidying, but the concept is > still the same. I am cc'ing infrastructure@, so if there is any change from > this infrastructure policy, the team can let everyone know. Otherwise, I > think that this remains policy. > > John Keys asked: > > Is it not enough to have the source of the site in CVS? For example, > > the xdocs (and associated artifacts) for a maven generated site. Is > > there an added benefit to having the generated HTML in CVS also? > > In the event of some sort of failure, e.g., an accidental deletion or some > other problem, the infrastructure team cannot be assumed to have access to > the tools, nor knowledge to use them. Plus it would take much longer to > restore by re-building than by doing an update from CVS. Shouldn't this be covered by some sort of backup, rather than having CVS as the placeholder? Or by zipping the current site and storing it in an archives directory. Since the sites are almost always generated from tools, having the source and the result in CVS seems overkill. If a project site was to be down due to hardware issues, a small wait while the project team brought it back up shouldn't be too bad. > There is also an oversight issue. If there were some sort of defacement > (there was a perceived one last year), it can be checked against CVS records > (turned out that it was not a hack, just an ill-advised comment that a > Commiter had checked in). And those CVS records can be checked against > replicated copies. It's far easier to oversee the source than the resulting HTML. In my experience, limited though it is, almost noone read the HTML commits, as they were assumed to be generated from the source. > Those are just a few things that occur to me off-hand. I am sure that those > who developed the policy in the first place have even more reasons, and > experiences behind them. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
