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

[Chad Berkley]

Hi Carlos,

The problem I see with this is that it divides kepler into project 
specific lines where what we're trying to do is create a cross project 
modeling platform.  Our src directly was already divided similarly to 
this and it caused numerous problems with organization so we've been 
trying to move stuff to the org.kepler tree.  Also, reorganizing stuff 
on that level at this point would be a nightmare.

chad

Carlos A. Rueda wrote:
> 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
>>
> 
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev