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

[Carlos A. Rueda]

Dear kepler-ers,
I think having the two modules kepler/pubs and kepler/dev is a very 
good idea.  In fact (knowing that the current KSW efforts might 
supersede the following suggestion somehow), I would suggest even go 
further and split up the /dev module into submodules corresponding to 
projects, something like:
    kepler/dev/core
    kepler/dev/projA
    kepler/dev/projB
    ...

with each component (submodule) coming with its own build files 
(build.xml, properties, etc.) and dependencies only on those other 
required modules.

Developer-users would be able to check out only the desired 
components. This way one can avoid dealing always with the "heavy" 
kepler and instead work with the minimum set of components required to 
try and test new developments.

carlos

Bertram Ludaescher wrote:
> Chad Berkley writes:
> ...
> 
>  > a slightly different way.  Say kepler/dev and kepler/pubs.  That way if 
>  > you only want the code part you could do 'cvs co kepler/dev'  If you 
>  > want it all, you would do 'cvs co kepler'.  Just a thought.
> 
> Looks like that easiest fix to me. Any objections to this suggestion?
> (Would take care of both Chad's problem and the concern that Laura raised)
> 
> BTW, I also think that a document management might be too much effort
> right now. An interesting project though for someone who is interested
> in that topic ..
> 
> Bertram
> 
>  > 
>  > chad
>  > 
>  > Laura L. Downey wrote:
>  > > I thought the point was having everything in one place -- which is important
>  > > with a distributed project.  At least that is the impression I've gotten
>  > > from Matt.
>  > > 
>  > > It would seem that people are "checking out" instead of "updating" with CVS
>  > > because update is much quicker.  But I think I remember Dan telling me the
>  > > other day that it is "safer" to check out than to update.
>  > > 
>  > > I'm fine with whatever is decided, keeping things together or splitting them
>  > > apart.  My only comment is that the more repositories we have and the more
>  > > places we have to go to get and put data (docs, code etc), the more upkeep
>  > > that is for everyone.
>  > > 
>  > > Laura L. Downey
>  > > Senior Usability Engineer
>  > > LTER Network Office
>  > > Department of Biology, MSC03 2020
>  > > 1 University of New Mexico
>  > > Albuquerque, NM  87131-0001
>  > > 505.277.3157 phone
>  > > 505.277-2541 fax
>  > > ldowney at lternet.edu
>  > >  
>  > > 
>  > > -----Original Message-----
>  > > From: kepler-dev-bounces at ecoinformatics.org
>  > > [mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Shawn Bowers
>  > > Sent: Thursday, August 04, 2005 12:02 PM
>  > > To: Chad Berkley
>  > > Cc: Kepler-Dev
>  > > Subject: Re: [kepler-dev] breaking off a kepler-docs repository
>  > > 
>  > > 
>  > > 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
>  > _______________________________________________
>  > 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
>