[kepler-dev] [Fwd: [kepler-cvs] kepler/src/exp/ptolemy/actor/process ProcessThread.java]
altintas at sdsc.edu
Tue Oct 25 09:32:56 PDT 2005
I agree. In the future, we'll discuss these things on Kepler-dev.
I actually like Shawn's idea of making sure that any code that will
affect the core is bullet-proof before it is checked in. I don't know a
good way of doing this. (Considering our experience in the past with
setting up code reviews.) Any suggestions?
On Oct 25, 2005, at 8:57 AM, Bertram Ludaescher wrote:
> 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..
>>>> On Tue, 25 Oct 2005 08:36:13 -0700
>>>> Ilkay Altintas <altintas at sdsc.edu> wrote:
> 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
> 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> We sure need to be careful about what to check in as exp, but we
> IA> need to check these in somehow. We can't check them into Ptolemy
> IA> without testing them further IMHO.
> IA> Any ideas on how to do these check-ins more robust?
> IA> Thanks,
> IA> -ilkay
> IA> On Oct 25, 2005, at 8:18 AM, Chad Berkley wrote:
>>> 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.
>>> 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
>>>> 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,
>>>> -------- Original Message --------
>>>> Subject: [kepler-cvs] kepler/src/exp/ptolemy/actor/process
>>>> 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
>>>> 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
>>>> Kepler-dev mailing list
>>>> Kepler-dev at ecoinformatics.org
>>> Kepler-dev mailing list
>>> Kepler-dev at ecoinformatics.org
> IA> _______________________________________________
> IA> Kepler-dev mailing list
> IA> Kepler-dev at ecoinformatics.org
More information about the Kepler-dev