openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eddie O'Neil" <ekon...@gmail.com>
Subject Re: staging of site changes
Date Wed, 26 Jul 2006 03:20:25 GMT
  Agreed -- the CTR process has worked well for Beehive.  Basically,
we commit the documents for the site to SVN and use Forrest (or some
other site generation tool) to convert these XML files into the site's
.html files.  Both the source documents and website are committed to
SVN.

  Then, both the changed documents and the built site are committed to
SVN where they can be reviewed.

  Once the changes have been reviewed, the live site is updated by
running an "svn co" on the ASF server in the /www directory.

  Note, this applies only to the site itself -- the documentation for
each release is just copied to the appropriate location on the server.
 It's generally good to avoid committing generated Javadoc to SVN.  :)

Eddie




On 7/25/06, robert burrell donkin <robertburrelldonkin@gmail.com> wrote:
> On 7/25/06, Patrick Linskey <plinskey@bea.com> wrote:
> > Hey,
> >
> > Does apache have any infrastructure / conventions in place for staging
> > changes to the site to look them over / collaborate / etc. before
> > pushing them to the site?
>
> web pages are staged at people.apache.org before being rsync'd to
> www.apache.org. it is possible to review changes before this happens -
> see http://www.apache.org/dev/project-site.html.
>
> however, this doesn't sound what you're looking for
>
> in terms of general review, the standard procedures are review then
> commit (RTC) and commit then review (CTR). when CTR is being used, all
> committers should read and review the commit email. when RTC is being
> used, committers use JIRA to post their proposed changes and then wait
> till the vote passed.
>
> but this probably isn't what you wanted to know either :-)
>
> a common way of gathering feedback, the usual approach is to use your
> personal webspace (http://people.apache.org/~rdonkin in my case) to
> host the documentation on a temporary basis. this approach has
> limitations when it comes to collaboration. unless the source is
> committed, there are limits to the quantity of collaboration that's
> possible. it's good for people posting a few corrections and
> improvement but deep collaboration between a group of documentors
> probably requires a branch.
>
> http://www.apache.org/dev/new-committers-guide.html#public_html covers
> the personal web space for committers.
>
> - robert
>

Mime
View raw message