[kepler-dev] RFC new directory structure

[Matt Jones]

Hi David,

My comments inline again.

David Buttler wrote:
> Hi Matt,
> 
> Thanks for your comments.  One thing that I would like to point out is 
> that neither Xiaowen or myself can make any changes in the CVS 
> repository as we are not 'official' members yet.  If possible, I would 
> like to have Xiaowen get commit access to the repository (I probably 
> don't need it at the moment), so that she can either help with these 
> changes that we have proposed, or start working on other parts of the 
> project.  It feels a little odd to not yet have anyone in our 
> particular  organization that can do anything other than read the 
> repository. Is it possible to get you, or one of the other full members 
> to initiate a vote on granting Xiaowen access?
> 
> [snip]
> [conversation continued below]
The Kepler model, as Bertram just pointed out, is to grant write access 
after someone has demonstrated a commitment to the ideals of the 
project.  This is modeled after the very successful Apache Software 
Foundation model, and has worked well for us in cross-institutional 
projects in the past.  It isn't meant to keep people from contributing, 
but rather to make membership be merit-based (based on contributions) 
rather than politically/institutionally based.  I think it shouldn't be 
too hard to get membership status if someone is working on the project 
part or full time, but part of the requirement should be a demonstrated 
interest in Kepler itself.  That said, I think Ilkay will be proposing 
membership soon for some people that have been contributing.

[snip]

>>> 2. demos.htm and ptolemy-index.html should probably be moved out of lib/
>>> and into a more appropriate folder, probably into src/.
>>
>>
>>
>> I guess I conceive of lib as the location of resources (such as 
>> required libraries, html, xsl files, etc that are needed for an app to 
>> run), while src is for java code, etc.  I'm not convinced this is a 
>> good proposal yet.
>>
> I was thinking of lib as a source of code libraries (jars and dlls).  I 
> don't think HTML belongs in there. the ptolemy-index.html is part of the 
> user interface / user documentation for Ptolemy, and should be placed in 
> the same directory as the rest of the built-in user documentation.  
> Currently, we have 'website' and 'docs' and I am not exactly clear on 
> the meaning of the docs directory.  From browsing through it, it looks 
> like developer documentation [the screenshots you did for the actor/data 
> source view look really, really, cool; unfortunately for me I am not 
> sure how to view a psd on my linux box -- thats a photoshop format 
> right?].  Do we need three different directories -- one for the web 
> site, one for developer documentation, and one for bundled user 
> documentation?  I could easily be convinced of this, but it also seems 
> possible to combine them all.
This clearly needs more discussion before a change is made.  The main 
developers to-date (Ilkay, Chad, Efrat, Cheng) should weigh in before we 
decide.

> 
>>>
>>> 3. Ilkay will dispose of lib/forBerkeley/ and lib/forSB/ folders or move
>>> them into the top-level test/ folder since they contain testing material
>>> and so don't belong in lib/.  Whoever's responsible for
>>> lib/ecoPipelines/ should probably do the same because that's testing
>>> material also as I understand it.
>>
>>
>> agreed.  The "test" folder should contain 1) directory structures that 
>> lead to JUnit source files, and 2) the resources such as testing data 
>> that is needed to run those or other tests.
>>
> Is there any more documentation on the JUnit tests that have already 
> been implemented?  I don't remember seeing any ant target to execute 
> them; test driven development has been something I have been meaning to 
> learn more about for awhile now...
> 
>>
>>>
>>> The existence of src/exp/ seems a bit questionable.  It seems to stand
>>> for "experimental".  Maybe it's time to either make it stable and
>>> incorporate it into an existing project, or delete it ...
>>
>>
>> Sure.  exp is a questionable practice.  But at times it is ueful as a 
>> scratch area to get stuff into CVS for sharing that is not (or should 
>> not) be in the build process.  If it is put into "src", it'll be built 
>> automatically by ant unless the build.xml is modified to specifically 
>> exclude it.
>>
> This seems to be a difficult question.  We certainly want to make sure 
> developers can work on experimental code.  Does your suggestion of 
> having a branch not cover this type of situation?  Since this particular 
> code is extensions to ptolemy, perhaps it needs to be treated 
> differently than the rest of the source code?

Branches would proabbaly work fine for this, better than the current 
solution. See my other email I just sent a minute ago for details.

> 
>>>
>>> Please comment!  If nobody objects to the proposed restructuring here, I
>>> can do nothing but assume everybody loves it =)  We'd like to get this
>>> finalized as soon as possible, which would make it easier to create a
>>> distribution.  Matt will be back next week from travel I believe, and it
>>> would be wonderful to have some kind of rudimentary installer for him.
>>
>>
>>
>> These are huge (but good) changes.  Finalizing it quickly is good, but 
>> be sure to give everyone time to react, considering that some key 
>> developers (e.g., Chad) are traveling.  I think at least 1 week for 
>> comments after the final revisions to the scheme is appropriate.  I 
>> think a formal proposal and vote is warranted for a change of this 
>> magnitude.
>>
> How would we go about making this a more formal proposal that we have 
> already?

What you've done is good.  We just need to give people time to respond 
to the changes, and then revise the proposal as we go, and when we're 
all happy with it (in a week or two), someone should be charged with 
making the changes.  Making such extreme changes will break a lot of 
things, so I suggest that someone who is very familiar with the code and 
helped create the original build (me, ilkay, or chad) should make the 
changes we agree to on be sure everything works well and we minimize 
disruption to the project.

Matt

> 
> Dave
> 
>> Matt
>>
>>>
>>> Xiaowen
>>
>>
>>

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------