[kepler-dev] Re: [SDM-SPA] RFC new directory structure

Vouk vouk at ncsu.edu
Wed Mar 17 20:36:58 PST 2004

I like Matt's branching and notational model.

Matt Jones wrote:

> Some more build comments, follwoing on my earlier comments:
> Xiaowen Xin wrote:
>> Hi Mladen,
>> Actually, right now, new development goes into src/ just like all other
>> source code.  As long as it compiles and it doesn't disrupt other
>> people's classes, it's allowed in src/.  But of course this wouldn't
>> work for the few days/weeks leading up to the release.  We should
>> probably have a code freeze for a period of time before the release so
>> that we can all test it and make sure it works.
>> I think the best way to deal with this is to have branches in CVS.  I
>> believe this is how most major projects do it.  So we could have a
>> stable branch, from which we would make a release.  In addition, we
>> would have a development branch where untested code will go.
> Agreed. This reiterates my emails from earlier.
>> So we don't need development directories.  We just need a development
>> branch in CVS.
> I prefer to model the tree as a semi-stable development version, with 
> branches added for 1) highly experimental work, and 2) releases as 
> they are stabilized, and 3) patches to those releases.  This allows 
> development to continue while the release is debugged.  Here's an 
> example tree CVS revision tree for one file:
>                           KEPLER-1_0_0_BRANCH             KEPLER-1_0_0
>                        -- -- -- --
>                       /
> 1.0 -- 1.1 -- 1.2 -- 1.3 -- 1.4 -- 1.5 -- 1.6 -- 1.7 --1.8
>                              \
>                              EXP_FEATURE1_BRANCH
>                               -- -- --
> Of course, this model requires that both the release bug fixes (e.g., 
> from and experimental features (from must be merged 
> into the HEAD when they are finished, else they be lost from the tree. 
> The alternative (of having separate development branches) requires 
> many more merge operations, which are hard.  So, I think this is the 
> most stable model for developers, because it keeps the development 
> tree on the trunk.  There are a number of treatises on the web about 
> how to use CVS in a team environment, and this is a common (maybe even 
> preferred) model for shared code repositories to minimize merging 
> while maximizing stability.
>> While we're on the topic, Zhengang has suggested that we outline a
>> release schedule and goals for our next release.  I think that's a great
>> idea because I personally would really like to see a release soon to
>> give to Matt.  So any suggestions/proposals? =)
> Me too.  I already proposed a schedule in one of my earlier emails, 
> but got no responses from anyone.  My target milestones are listed in 
> Bugzilla for Kepler.  Any problems with that schedule?
>> Regarding jar files in lib/, yes you're right, we didn't discuss
>> dividing that up by subproject.  Do you see a need to?
> No.
>> This is also true for bin/, which at the moment isn't a problem because
>> we have only two files to put in there: runVergil.sh and runVergil.bat.
> No need for bin.
> Matt
>> Xiaowen
>> On Wed, 2004-03-17 at 15:37, Vouk wrote:
>>> Xiaowen,
>>> Where does new development go, and stuff in progress?
>>> Programmer X works on item Z. Does not
>>> finish it that day, goes home.
>>> Normally, I would say, put it into a development
>>> archive (shared nevertheless and put a lock on it),
>>> but do not leave it on your machine, the latter may
>>> not exist in the morning.
>>> Do you plan to have development directories
>>> (or are we just discussing integrated release level codes?)
>>> It also looks like the jar and lib files will be a mixture
>>> of project-specific and shared items (according to
>>> the sctructure below). Is that true or am I misreading it?
>>> Same for bins etc.
>>> ?
>>> Thanks
>>> Mladen
>> _______________________________________________
>> kepler-dev mailing list
>> kepler-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev

More information about the Kepler-dev mailing list