[kepler-dev] [Fwd: [kepler-cvs] kepler/src/exp/ptolemy/actor/process ProcessThread.java]
Bertram Ludaescher
ludaesch at ucdavis.edu
Tue Oct 25 08:57:31 PDT 2005
Hi Ilkay:
Maybe one thing to avoid surprises would be to run part of the
discussion over kepler-dev (as you suggest) since not everybody is on
IRC--actually nobody is on IRC all the time ;-)
Also, since kepler-dev is archived, one can always go back to see why
particular decisions were made..
my $0.02 on this..
Bertram
>>> On Tue, 25 Oct 2005 08:36:13 -0700
>>> Ilkay Altintas <altintas at sdsc.edu> wrote:
IA>
IA> Hi Guys,
IA> How to do this best was asked and discussed (with the few who
IA> responded) on the Kepler irc channel before Oscar has checked in the
IA> new classes to the exp directory. Next time we'll also query on the
IA> kepler-dev for ideas before we do such a change.
IA>
IA> We sure need to be careful about what to check in as exp, but we also
IA> need to check these in somehow. We can't check them into Ptolemy
IA> without testing them further IMHO.
IA>
IA> Any ideas on how to do these check-ins more robust?
IA>
IA> Thanks,
IA> -ilkay
IA>
IA>
IA> On Oct 25, 2005, at 8:18 AM, Chad Berkley wrote:
IA>
>> Yeah, I'm not sure this is a good idea adding so many exp files. I
>> think these changes can probably be made in the PTII tree if they're
>> essential. I think we really need to minimize the number of classes
>> in the exp directory or we're going to be in for a huge headache the
>> next time those classes change in PTII.
>>
>> chad
>>
>> On Oct 24, 2005, at 11:22 PM, Shawn Bowers wrote:
>>
>>>
>>> Hi all,
>>>
>>> I am getting a little nervous about some of the new checkins to exp.
>>> In particular, some of the fundamental classes like IOPort, Manager,
>>> StaticScheduler, etc. I think it would be great if prior to checking
>>> in fundamental classes such as this into the exp directory, if a few
>>> folks could make sure they are "bullet proof" ... perhaps this has
>>> already been done. My concern is that this has the potential of
>>> adding bugs that may be very hard to find for folks.
>>>
>>> Also, Oscar, you might want to send a note to kepler-dev explaining
>>> what changes you are making to these classes. I think these are the
>>> first non-gui type classes that have been modified within Kepler, so
>>> it would be educational for us to hear what changes were necessary,
>>> etc.
>>>
>>> Thanks,
>>> -shawn
>>>
>>> -------- Original Message --------
>>> Subject: [kepler-cvs] kepler/src/exp/ptolemy/actor/process
>>> ProcessThread.java
>>> Date: Mon, 24 Oct 2005 20:38:20 -0700 (PDT)
>>> From: barney at ecoinformatics.org (Oscar Barney)
>>> To: kepler-cvs at ecoinformatics.org
>>>
>>> barney 05/10/24 20:38:20
>>>
>>> Removed: src/exp/ptolemy/actor/process ProcessThread.java
>>> Log:
>>> removed because of reasons that Christopher Brooks mentioned(it
>>> is important
>>> and being modified allot by the ptolemy people). ProcessThread did
>>> not preform
>>> a critical function with the Provenance listener and we can work
>>> probably work
>>> around having it modified.
>>> _______________________________________________
>>> Kepler-cvs mailing list
>>> Kepler-cvs at ecoinformatics.org
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/
>>> kepler-cvs
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at ecoinformatics.org
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/
>>> kepler-dev
>>>
>>>
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-
>> dev
IA>
IA> _______________________________________________
IA> Kepler-dev mailing list
IA> Kepler-dev at ecoinformatics.org
IA> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
More information about the Kepler-dev
mailing list