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

[David Buttler]

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]

>
> I think a top level workflows directory is a great idea.  Again, I 
> think a functional classification is best, but the organizational one 
> you propose would be an improvement.  Does it really matter which 
> organization developed which workflow, and that the package structure 
> reflect that?  I think not, but I come from a functional rather than 
> political perspective on this.
>
Unfortunately, it is a requirement to have a clear separation for SPA 
project contributions.  I really like your idea of providing multiple 
function-based views of the actors.  This seems like it could be a major 
improvement to the user interface.

>>
>> 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.

>>
>> 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?

>>
>> 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?

Dave

> Matt
>
>>
>> Xiaowen
>
>