+1 for (1). If we do (1) or (2), what should we do for making sure that the patch is good?
Nicholas ----- Original Message ---- > From: Doug Cutting <[EMAIL PROTECTED]> > To: core-dev@hadoop.apache.org > Sent: Monday, December 1, 2008 12:54:35 PM > Subject: commit Forrest output? > > We currently re-generate PDF and HTML documentation whenever we commit a > documentation patch, which creates huge commit messages that few read. This > was > originally done so that folks who check out the sources from subversion did > not > need to install forrest in order to read the documentation. > > Perhaps we should change this. Some options: > > 1. Do not commit Forrest output at all. Documentation would be generated as > a > part of release builds, or when a developer wanted to browse it, just as > javadoc > is. Documentation on the website would be extracted from the release > tarball, > just as javadoc is. > > 2. Do not commit Forrest output except when preparing for a release. > > 3. Keep committing Forrest output each time a documentation change is made. > > (I'm speaking here about the versioned documentation, that's included in > releases, not the project website, which we commit for a different reason--so > that ops can quickly rebuild it--and that changes more slowly.) > > My preference would be for (1). Thoughts? > > Doug
