This page provides an overview of the tools Apache projects use to manage their own websites, and the tools used to manage the overall apache.org website. Everyone, even non-committers, can suggest changes to any Apache project website using these tools; committers on each project can use them to easily update their website very easily.
More notes about website generation are also found on infra-site.html.
Every Apache project or podling has a website hosted at apache.org that is maintained by one of these tools. It is up to each project to decide the details of how their own website is maintained and what software is used - as long as it results in static files that can be served by the our public web servers (limited support for .htaccess files and CGI scripts is also available).
The basic requirements for site management are that only committers should be able to modify the site and that notifications of all site changes should be sent to the relevant project mailing lists. The Apache CMS allows non-committers to send patches via a simple web interface by "Mail Diff"ing to the project mailing list that can be easily published by a committer.
The infrastructure team currently supports two primary tools for publishing and maintaining Apache project websites:
http://project.apache.org/. The project team can use any site build mechanism it wants as long as the above requirements are met.
For svnpubsub sites, review the local files in your svn checkout before committing them. The changes will be published immediately after you commit them.
For CMS sites, just commit the changes (without "publish"-ing them) and browse
http://TLP.staging.apache.org/. (For example, the staging version of
this page.) The CMS
web interface includes a [Staged] link that will take you there directly.
Yes, the central config file allows you to use
.htaccess files in your
website directories to control configuration. Of course, reading and
.htaccess file on each request can slow down the server, so
you should consider requesting an adjustment in the central config file for
permanent configuration changes.
Each day's error and access logs are kept in
www.apache.org:/x1/logs/www/. They are shuffled off each night to a
people.apache.org:/x1/logarchive/ and are then
periodically archived to other media.
No formal log analysis is performed, but you are free to grab the logs and do whatever analysis you would like.
Yes. Infrastructure requires the generated site files to be in a Subversion tree somewhere, and published via svnpubsub. For CMS users this tree will be the CMS build output tree.)
Look at the
.revision file at the root of your site (for example,
http://subversion.apache.org/.revision). That file is updated after every
svn update. (If the update is underway or exited abnormally,
.revision won't have been changed.)
Some projects have a "mail" directory at the top of their project website.
Enable this by creating a symbolic link in svnpubsub or CMS output
Also see other notes.
Yes, just add a
favicon.ico file to your site's root. The feather is only
used for project sites that don't have a
If you are using svnpubsub, the commit will perform very slowly if the number of changes is large - particularly if the number of files is large. This is often the case with JavaDoc, and to a lesser extent Maven generated sites.
You may wish to use the CMS instead of svnpubsub directly. This moves the work to the server-side, but it will still be valuable to minimize the changes committed.
These are some steps that can be taken:
-notimestampoption. This will avoid most files from being modified between runs if there haven't been code changes.
svn copyoperation to tag or branch the content, rather than checking in a complete copy