Return-Path: 
 <docs-cvs-return-566-apmail-perl-docs-cvs-archive=perl.apache.org@perl.apache.org>
Delivered-To: apmail-perl-docs-cvs-archive@perl.apache.org
Received: (qmail 16320 invoked by uid 500); 14 Apr 2002 07:14:48 -0000
Mailing-List: contact docs-cvs-help@perl.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:docs-cvs@perl.apache.org>
List-Help: <mailto:docs-cvs-help@perl.apache.org>
List-Unsubscribe: <mailto:docs-cvs-unsubscribe@perl.apache.org>
List-Subscribe: <mailto:docs-cvs-subscribe@perl.apache.org>
Delivered-To: mailing list docs-cvs@perl.apache.org
Received: (qmail 16309 invoked by uid 500); 14 Apr 2002 07:14:48 -0000
Delivered-To: apmail-modperl-docs-cvs@apache.org
Date: 14 Apr 2002 07:14:46 -0000
Message-ID: <20020414071446.62428.qmail@icarus.apache.org>
From: stas@apache.org
To: modperl-docs-cvs@apache.org
Subject: cvs commit: modperl-docs TODO
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

stas        02/04/14 00:14:46

  Modified:    .        TODO
  Log:
  - add my todo notes on a better updating process
  
  Revision  Changes    Path
  1.34      +43 -1     modperl-docs/TODO
  
  Index: TODO
  ===================================================================
  RCS file: /home/cvs/modperl-docs/TODO,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- TODO	13 Apr 2002 15:02:08 -0000	1.33
  +++ TODO	14 Apr 2002 07:14:46 -0000	1.34
  @@ -80,11 +80,53 @@
     STATUS: on hold
   
   ====================================================================
  +*** Updating process tuning ***
  +
  +I'm thinking to use cron to update the site, on let's say 6 hours
  +basis. Currently I manually execute an update script which does:
  +
  + cd /www/perl.apache.org/preview/modperl-docs
  + cvs up
  + bin/build -f
  + bin/makeindex (for search)
  +
  +since a complete site rebuild including pdf generation is a very heavy
  +operation, for efficiency we need to extend the update mechanism to
  +do:
  +
  +* build + makeindex only if cvs up indicated that things were
  +  changed. That means that we need something like VCS::CVS to get the
  +  control over cvs.
  +
  +futher optimizations:
  +
  +* rerun makeindex only if things under src/ have changed
  +
  +* run build -df only if things under tmpl/, src/images or lib/ have
  +  changed
  +* otherwise run build -d (without -f), the code will figure out what
  +  should be updated by itself.
  +
  +If we do this, no one will need to ssh to the site and manually update
  +the site.
  +
  +One thing to think about: what if something goes broken, e.g. someone
  +has committed code to lib/ and didn't manually verify that everything
  +builds properly. Then on the next automatic update, things go kaboom
  +and the site could become unusable. Any ideas how to prevent this?
  +Currently I haven't planned using cvs for the autogenerated site.
  +
  +Anybody can help me to replace the 4-liner update script with a more
  +elaborate one?
  +====================================================================
   
   Later:
   ------
   
  -- Think about porting the conferences stuff
  +- Think about porting the conferences stuff.
  +  when we have an internal resource, link to it from
  +  src/help/index_top.html
  +
   
   - add feather in the tail
   <img src="[% doc.dir.abs_doc_root %]/images/feather_transbg.gif" width=194 height=80 alt="ASF feather"> 
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-cvs-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-cvs-help@perl.apache.org