> 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>>
> _______________________________________________
> 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/14905.php