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

[Vouk]

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.
>  
>
Branches will work.

>So we don't need development directories.  We just need a development
>branch in CVS.
>
That is fine, no problem so long as we can distinguish different 
branches/trains.

>
>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? =)
>
Excellent idea. I will shake the NCSU "branch" to gather input.
SDSC "branch"?
Others?

>
>Regarding jar files in lib/, yes you're right, we didn't discuss
>dividing that up by subproject.  Do you see a need to?
>
We may want to since not all projects may want to have all lib code on 
all occasions.
Specail

>
>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.
>
Ditto as above.

Special occastions could be dealt with by "branch" markings?

Mladen

>
>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
>>    
>>
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20040317/368caccb/attachment.html>