incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [RT] Super Simple Site Generation Tool
Date Thu, 29 Dec 2005 21:32:02 GMT


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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message