Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework
From: Thomas Naughton (naughtont_at_[hidden])
Date: 2014-05-29 10:26:23


Hi,

Thanks Jeff, I think that was a pretty good summary of things.

> Thomas indicated there was no rush on the RFC; perhaps we can
> discuss this next-next-Tuesday (June 10)?

Phone discussion seems like a good idea and June 10 sounds good to me.

Thanks,
--tjn

  _________________________________________________________________________
   Thomas Naughton naughtont_at_[hidden]
   Research Associate (865) 576-4184

On Thu, 29 May 2014, Jeff Squyres (jsquyres) wrote:

> I refrained from speaking up on this thread because I was on travel, and I wanted to think a bit more about this before I said anything.
>
> Let me try to summarize the arguments that have been made so far...
>
> A. Things people seem to agree on:
>
> 1. Inclusion in trunk has no correlation to being included in a release
> 2. Prior examples of (effectively) single-organization components
>
> B. Reasons to have STCI/HPX/etc. components in SVN trunk:
>
> 1. Multiple organizations are asking (ORNL, UTK, UH)
> 2. Easier to develop/merge the STCI/HPX/etc. components over time
> 3. Find all alternate RTE components in one place (vs. multiple internet repos)
> 4. More examples of how to use the RTE framework
>
> C. Reasons not to have STCI/HPX/etc. components in the SVN trunk:
>
> 1. What is the (technical) gain is for being in the trunk?
> 2. Concerns about external release schedule pressure
> 3. Why have something on the trunk if it's not eventually destined for a release?
>
> In particular, I think B2 and C1 seem to be in conflict with each other.
>
> I have several thoughts about this topic, but I'm hesitant to continue this already lengthy thread on a contentious topic. I also don't want to spend the next 30 minutes writing a lengthy, carefully-worded email that will just spawn further lengthy, carefully-worded emails (each costing 15-30 minutes). Prior history has shown that we discuss and resolve issues much more rationally on the phone (vs. email hell).
>
> I would therefore like to discuss this on a weekly Tuesday call.
>
> Next week is bad because it's the MPI Forum meeting; I suspect that some -- but not all -- of us will not be on the Tuesday call because we'll be at the Forum.
>
> Thomas indicated there was no rush on the RFC; perhaps we can discuss this next-next-Tuesday (June 10)?
>
>
>
>
> On May 27, 2014, at 12:25 PM, Thomas Naughton <naughtont_at_[hidden]> wrote:
>
>>
>> WHAT: add new component to ompi/rte framework
>>
>> WHY: because it will simplify our maintenance & provide an alt. reference
>>
>> WHEN: no rush, soon-ish? (June 12?)
>>
>> This is a component we currently maintain outside of the ompi tree to
>> support using OMPI with an alternate runtime system. This will also
>> provide an alternate component to ORTE, which was motivation for PMI
>> component in related RFC. We build/test nightly and it occasionally
>> catches ompi-rte abstraction violations, etc.
>>
>> Thomas
>>
>> _________________________________________________________________________
>> Thomas Naughton naughtont_at_[hidden]
>> Research Associate (865) 576-4184
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/05/14852.php
>
>
> --
> Jeff Squyres
> jsquyres_at_[hidden]
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/05/14904.php
>