Tue Mar 22 16:37:17 PST 2005
in the larger group has almost always resulted in faster resolution of
an issue (e.g., the Ptolemy folks often chime in with good advice, and
so do others) adn not in a slow down. As the group becomes larger
we'll see how this goes, but so far I think this has been a success.
Should we have vote on that?
>>>>> "MJ" == Matt Jones <jones at nceas.ucsb.edu> writes:
MJ> Hi David,
MJ> My comments inline again.
MJ> 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?
>> [conversation continued below]
MJ> The Kepler model, as Bertram just pointed out, is to grant write access
MJ> after someone has demonstrated a commitment to the ideals of the
MJ> project. This is modeled after the very successful Apache Software
MJ> Foundation model, and has worked well for us in cross-institutional
MJ> projects in the past. It isn't meant to keep people from contributing,
MJ> but rather to make membership be merit-based (based on contributions)
MJ> rather than politically/institutionally based. I think it shouldn't be
MJ> too hard to get membership status if someone is working on the project
MJ> part or full time, but part of the requirement should be a demonstrated
MJ> interest in Kepler itself. That said, I think Ilkay will be proposing
MJ> membership soon for some people that have been contributing.
>>>> 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.
MJ> This clearly needs more discussion before a change is made. The main
MJ> developers to-date (Ilkay, Chad, Efrat, Cheng) should weigh in before we
>>>> 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?
MJ> Branches would proabbaly work fine for this, better than the current
MJ> 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
>> How would we go about making this a more formal proposal that we have
MJ> What you've done is good. We just need to give people time to respond
MJ> to the changes, and then revise the proposal as we go, and when we're
MJ> all happy with it (in a week or two), someone should be charged with
MJ> making the changes. Making such extreme changes will break a lot of
MJ> things, so I suggest that someone who is very familiar with the code and
MJ> helped create the original build (me, ilkay, or chad) should make the
MJ> changes we agree to on be sure everything works well and we minimize
MJ> disruption to the project.
MJ> Matt Jones jones at nceas.ucsb.edu
MJ> http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
MJ> National Center for Ecological Analysis and Synthesis (NCEAS)
MJ> University of California Santa Barbara
MJ> Interested in ecological informatics? http://www.ecoinformatics.org
MJ> kepler-dev mailing list
MJ> kepler-dev at ecoinformatics.org
More information about the Kepler-dev