Ross Gardler wrote:
Geir Magnusson Jr. wrote:
a) edit
b) render
c) examine. if not right, GOTO a)
d) commit
e) deploy
a,c are entirely my choice of tool, so it's easy.
d,e use one standard common tool. it's easy.
b needs to be simple and easy
The ForrestBot does b, d and e of your, i.e. the three steps that you
don't list as "entirely my choice of tool".
True, becuase it's SVN. I suppose that to be fair, there are tools for
SVN now ;) like integration into editors and nice plugins for windows
or something. But I just use svn on the command line everywhere I go,
and I mis-thought, I guess.
Although e) can not be done
on ASF harware until there is a way such a tool can push the content to
the live servers (same problem for all tools). Of course, it can do the
preparation work, such as put it in a relevant SVN server for periodic
pull deployment to the servers.
I dunno. Here's how it works w/ the Harmony site :
ssh -l geirm minotaur.apache.org
cd /www/incubator.apache.org/harmony/
svn update
Now, we could probably just put a post-commit hook that does the deploy,
and maybe tailor it to a specific file, like DEPLOY.txt in the root or
such so that you just touch it, commit, and the site deploys, with the
added benefit that SVN will give us a log of who actually did the deploy
at a given time.
The advantage of the forrestbot is that if you have users who edit docs
but do not do b through e, then a cron job will reularly run the build
and report any problems via email. This also means there is a regularly
built staging area for people to independantly do c) without the need to
do b).
But I get nervous about not being able to do any QA - meaning the bits
that get deployed to "production" are never given even an cursory view
by the human that did the change.
It's like letting your app server build and deploy a WAR from source :)
I may be a luddite or something, but I don't trust that kind of
auto-deployment.
And if you don't buy my argument above, there's always the bit about
unintended consequences - w/ Forrest, I don't seem to be able to grok
what actually changes in the doc tree for some arbitrary change. That's
not terrible in itself, but w/o having to commit the generated artifacts
myself, I can't know if things changed that I didn't expect....
With checking in the artifacts, I do a svn commit and see the things
that change, and can find things that surprise me.
Couple this with other validation tools that can be set to run on the
staging area, e.g. link checkers, accessibility checkers erc. and you
have a level of automated validation of your site (we have not yet
integrated such tools in the ForrestBot).
Sure - and those could be used either way - a safety system always
running to check our site...
It's here, it works now and it is in use in production environments.
However, it is not a simple lightweight tool for local use, it still
suffers from the "Forrest is too much for our simple site needs" issue.
As you will see if you are a site-dev subscriber, I'm not objecting to
Leo doing this work, my only concen is the misinformation that is in
this thread conerning Forrest.
I'm not sure which misinfo....my POV on forrest comes entirely from
using it.
geir
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
