[kepler-dev] breaking off a kepler-docs repository

[Christopher Brooks]

I agree that having the docs available via CVS is a win, especially
for travelling.

We split the Ptolemy II docs in to a separate repository awhile back
and it has been a total win.  The user manuals are available as part
of the Windows installer, which most Ptolemy developers have on their
machines along with their CVS development tree.

I find it to be very useful to have the Ptolemy II tree not include
the docs when I'm checking out many trees to try to narrow down
a bug to just the few days when the change occurred.

I agree with Laura that it is somewhat less than convenient to have
the docs and the source in two trees.  However, we have a slightly
different set up in that we have a source repository, a separate
repository for the Ptolemy manual framemaker files and then yet another
repository for papers that are being developed by multiple authors.
Talks and published papers go on to the web site and are not checked
in to CVS, though they could be.

One can always use wget to pull over an entire subdirectory of
the website and get the talks and papers.


Anyway, the above is my $0.02.  I encourage you to split the 
docs into a separate repository.


Chad wrote:
> The nightly build should be working again now.  you probably saw the
> emails go by.  Feel free to add any unit tests or workflow tests.
> Note that workflow tests with visual components (i.e. Display, Plot,
> etc) still won't run correctly until we get X working on the server
> again.  

Locally, we are running Xvfb to provide X for some graphical tests.
My notes says
---start--
Xvfb is a virtual frame buffer that is installed on gigasource so that
the bldmastr user can run tests that use the X11 system.

    * Download Xvfb for Solaris from
      http://chartworks.com/support/server/XvfbonUnix.html
    * Grab the install.xvfb and xvfb.server scripts from
      http://developers.sun.com/solaris/articles/solaris_graphics.html
    * Edit xvfb.server. I needed to set X_OPTIONS to:

X_OPTIONS="-screen 0 1280x1024x32 -pixdepths 8 24 -fbdir /tmp -co $XVFB_DIR/rgb -fp $XVFB_DIR/fonts/misc/,$XVFB_DIR/fonts/Speedo/,$XVFB_DIR/fonts/Type1/,$XVFB_DIR/fonts/75dpi/,$XVFB_DIR/fonts/100dpi/ -sp $XVFB_DIR/SecurityPolicy"

    * Run install.xvfb
    * To test:

          Testing and Troubleshooting Once the X server is running,
          you can use your servlet application to confirm that Java
          platform graphics are working. If you have trouble, check
          that the X server is operating properly. As the user running
          the X display (tomcat by default) follow these steps,
          matching the value of -display to match your server:

          % /usr/openwin/bin/xclock -display :2 &

          You can use xwd (X window dump) to capture the image. Under
          the Solaris 9 OE, I find that /usr/openwin/bin/xwd crashes
          (see Sun bug id 4766571), so I use a copy I've obtained from
          the X11 distribution that I've placed in /usr/X11R6/bin:

          % /usr/X11R6/bin/xwd -display :2 -root -out /tmp/xclock.xwd

          Then copy the image file over to another system and display
          it to check that graphics are working, using xwud:

          % /usr/openwin/bin/xwud -in /tmp/xclock.xwdY

          If xclock won't run, then the server is probably not
          running. Make sure that xsun.server or xvfb.server is
          properly configured. 

--end--

_Christopher
--------

    One thing I like about using CVS for document management is being able 
    to travel with everything and access all of the docs even when I am not 
    network connected.  I find I often need access to powerpoint files and 
    word files in particular when I am on airplanes, and so I think whatever 
    solution we choose should allow a simple mechanism for downloading the 
    whole repository to local systems for offline access.
    
    Otherwise, I would be fine with separating out a document repository.
    
    Matt
    
    Shawn Bowers wrote:
    > I think it is a good idea to *not* include the various publications and 
    > presentations concerning Kepler in the code repository (cvs).
    > 
    > I wonder, however, if having a separate cvs for documents is the way to 
    > go.  Instead, maybe we should consider using a more traditional approach 
    > like a document management system? I'm sure there are a number of 
    > open-source/free ones out there (e.g., zope and plone are popular ones, 
    > the stanford publication server is an older one).  Perhaps there are 
    > also extensions of the wiki for this?
    > 
    > 
    > -shawn
    > 
    > 
    > 
    > 
    > Chad Berkley wrote:
    > 
    >>Hi all,
    >>
    >>As I sit here checking out kepler (again), waiting forever for the docs 
    >>directory to finish, it occured to me that it might be ok to have a 
    >>different cvs repository for kepler docs.  there's no reason why a 
    >>developer should have to checkout out a myriad of .doc and .ppt files 
    >>everytime you need a new version of kepler.  It seems to me that docs 
    >>that actually go with the kepler software should stay in the kepler 
    >>repository, but publications, reports and the like could be stashed 
    >>somewhere else.  Anyone have any reasons why this would be a bad idea?
    >>
    >>thanks,
    >>chad
    >>_______________________________________________
    >>Kepler-dev mailing list
    >>Kepler-dev at ecoinformatics.org
    >>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
    > 
    > 
    > _______________________________________________
    > Kepler-dev mailing list
    > Kepler-dev at ecoinformatics.org
    > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
    > 
    _______________________________________________
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org
    http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--------