[kepler-dev] Re: [SDM-SPA] RFC new directory structure
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
> -- 126.96.36.199 -- 188.8.131.52 -- 184.108.40.206 -- 220.127.116.11
> 1.0 -- 1.1 -- 1.2 -- 1.3 -- 1.4 -- 1.5 -- 1.6 -- 1.7 --1.8
> -- 18.104.22.168 -- 22.214.171.124 -- 126.96.36.199
> Of course, this model requires that both the release bug fixes (e.g.,
> from 188.8.131.52) and experimental features (from 184.108.40.206) 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?
>> 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.
>> On Wed, 2004-03-17 at 15:37, Vouk wrote:
>>> 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.
>> kepler-dev mailing list
>> kepler-dev at ecoinformatics.org
More information about the Kepler-dev