> Addressing Forrest first...Forrest is useful for both the site and > release documentation for a rew reasons: > > ... > > It's not clear that these steps can get much simpler without removing > Forrest entirely, which would (IMHO) be significantly more work in the > long run.
Right, I don't question that Forrest has real advantages, and for large amounts of content it's clearly a win -- but the version-independent site has been hovering around the ~20-25K worth of content for the past year, with almost all changes being small incremental diffs (like adding a new committer, adding FAQs, etc).. this leads me to ask whether the overhead is worth it. I totally see how Forrest helped with a large change like exiting the Incubator, but it seems like something on that scale is unlikely to happen to this content any time soon. That said, your point about being able to automate the nightly update of the current release docs leads me to suggest that we do the same for the site, which in my mind would smooth the path enough to make the use of Forrest for all content pretty much pain-free. > The reason to use SVN to manage the documentation is to enable easy > updates on the Apache web servers, but I'd guess that the SVN commit > of 32 MB of doc would take longer than the publishing steps below. :) This makes a lot of sense -- it sounds like Forrest essentially always does a "clean" build (ie pretty much all files get re-written even if there are no changes in them). Given that, and the ability to automate the update process on the server so that the only time you'd have to login to the server and do the tarball management yourself is if you couldn't wait for the nightly update, I think life is good. Do you know who has the ability to set up the automation? Is that something a project committer can do, or is it an infrastructure thing?
