Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Edgar Gabriel]

sounds good to me too.

Edgar

On 5/29/2014 10:04 AM, Joshua Ladd wrote:
> +1 I'm interested in hearing more. RTE is of interest.
> 
> Josh
> 
> 
> On Thu, May 29, 2014 at 10:33 AM, Ralph Castain  > wrote:
> 
> +1 for me!
> 
> On May 29, 2014, at 7:26 AM, Thomas Naughton  > wrote:
> 
> > 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
>  naught...@ornl.gov 
> >  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  > 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
>  naught...@ornl.gov 
> >>> Research Associate   (865)
> 576-4184 
> >>>
> >>> ___
> >>> devel mailing list
> >>> de...@open-mpi.org 
> >>> 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
> >> jsquy...@cisco.com 
> >> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> >>
> >> 

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Joshua Ladd]

+1 I'm interested in hearing more. RTE is of interest.

Josh


On Thu, May 29, 2014 at 10:33 AM, Ralph Castain  wrote:

> +1 for me!
>
> On May 29, 2014, at 7:26 AM, Thomas Naughton  wrote:
>
> > 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  naught...@ornl.gov
> >  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 
> 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
> naught...@ornl.gov
> >>> Research Associate   (865) 576-4184
> >>>
> >>> ___
> >>> devel mailing list
> >>> de...@open-mpi.org
> >>> 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
> >> jsquy...@cisco.com
> >> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> >>
> >> ___
> >> devel mailing list
> >> de...@open-mpi.org
> >> 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
> > de...@open-mpi.org
> > 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
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/05/14906.php
>

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Ralph Castain]

+1 for me!

On May 29, 2014, at 7:26 AM, Thomas Naughton  wrote:

> 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  naught...@ornl.gov
>  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  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  naught...@ornl.gov
>>> Research Associate   (865) 576-4184
>>> 
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> 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
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> 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
> de...@open-mpi.org
> 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

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Thomas Naughton]

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  naught...@ornl.gov
  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  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  naught...@ornl.gov
 Research Associate   (865) 576-4184

___
devel mailing list
de...@open-mpi.org
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
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

___
devel mailing list
de...@open-mpi.org
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

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Jeff Squyres (jsquyres)]

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  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  naught...@ornl.gov
>  Research Associate   (865) 576-4184
> 
> ___
> devel mailing list
> de...@open-mpi.org
> 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
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Ralph Castain]

On May 27, 2014, at 2:28 PM, George Bosilca  wrote:

> On Tue, May 27, 2014 at 5:09 PM, Ralph Castain  wrote:
>>> That being said, I agree with Ralph on the fact that accepting them in
>>> the trunk doesn't automatically qualify it for inclusion in any
>>> further stable release. However, if ORNL setup nightly builds to
>>> validate their module, I'm pretty certain nothing will stay against
>>> their inclusion in some future release.
>> 
>> I strongly disagree - we've discussed this at length before, and the issue 
>> of release schedule coordination is a deal buster. If people think it 
>> helpful to have their component in the devel trunk, I can somewhat absorb 
>> that one.
> 
> There is no such coordination issue in this particular case, as we
> don't coordinate with their releases. They maintain their component,
> check for the right version of their software and enable their
> component if every requirement is fulfilled.

Ah, but we do have to coordinate George. The scenario we encountered in this 
before was when someone needed to make a change in their component because of a 
change in their corresponding system. So the pressure mounted to generate a 
release from OMPI that would contain that revision - but that raised further 
issues. Was this a "bug" fix that could go in a stable series, as requested? 
How did we deal with their schedule vs ours in terms of what version of OMPI 
works with what version of their software?

Been thru this with Slurm (when we added some specific OMPI-support into Slurm) 
and it was a terrible problem. Finally had to break the connection at the end 
of 1.6 as both sides were too frustrated to continue it. It was just too hard 
to keep track of what version of Slurm worked with what version of OMPI, 
explaining and helping users to figure out the combinations, etc.

Now, that said - in these cases, we have a much smaller version of that 
problem. Only one STCI site (plus you folks in a less-critical role), and no 
HPX sites (outside of a couple of academic researchers) at this time. So 
coordination may indeed be something we simply offload to them - they can keep 
track of version-to-version matching at that small scale.


> 
>> Adding them to a release is a non-starter with me.
> 
> On which base are you making this assessment? This is a community
> based project, if one of the members of the community undergo the
> effort to develop and validate a specialized component and if they
> engage to follow up on the bug reports on their work, I don't see any
> valid ground we can forbid them from including their module on a
> stable release.

I agree that we have similar issues with other 3rd party libraries, and it has 
been interesting to watch the recent issues with MOFED on the user list in that 
regard. In some ways, I guess we could consider it in a similar light and argue 
that the coordination with RTE release mirrors things like OFED. Our current 
dependencies are on broader community libraries that undergo slow rates of 
change, not on independent libraries, and that does make some degree of 
difference. We also have never been asked to coordinate with those libraries - 
at least, not yet, though this entire discussion raises the question of "if we 
do it for them, then why not for others?".

So maybe you have the right approach to that issue. Let the contributing member 
wrestle with the woes of coordinating their releases on their end, with the RM 
on this end having the right to say "no" to pressures regarding schedule and/or 
modifications to stable release branches. Sadly it will definitely make the 
RM's life even harder as these pressures aren't always easy to resolve...but 
that will be the next guy's problem :-)

Will have to ponder more and hopefully deal with it if/when it becomes an 
issue. Your comments definitely sparked the thinking, though, so thanks!
Ralph


> 
>  George.
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/05/14871.php

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[George Bosilca]

On Tue, May 27, 2014 at 5:09 PM, Ralph Castain  wrote:
>> That being said, I agree with Ralph on the fact that accepting them in
>> the trunk doesn't automatically qualify it for inclusion in any
>> further stable release. However, if ORNL setup nightly builds to
>> validate their module, I'm pretty certain nothing will stay against
>> their inclusion in some future release.
>
> I strongly disagree - we've discussed this at length before, and the issue of 
> release schedule coordination is a deal buster. If people think it helpful to 
> have their component in the devel trunk, I can somewhat absorb that one.

There is no such coordination issue in this particular case, as we
don't coordinate with their releases. They maintain their component,
check for the right version of their software and enable their
component if every requirement is fulfilled.

> Adding them to a release is a non-starter with me.

On which base are you making this assessment? This is a community
based project, if one of the members of the community undergo the
effort to develop and validate a specialized component and if they
engage to follow up on the bug reports on their work, I don't see any
valid ground we can forbid them from including their module on a
stable release.

  George.

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Ralph Castain]

On May 27, 2014, at 1:50 PM, George Bosilca  wrote:

> From a practical perspective, I don't think there is a need for a
> phone call. Ralph made his point, and we all took notice of it.
> However, the proposed changes are in a single independent component,
> with no impact on the rest of the code base. Therefore, there is
> absolutely no valid reason not to be accepted in the trunk (ORNL
> already signed the contribution agreement). The fact that they are
> used by a single institution might be a little unsettling, but we do
> have precedents on this area.

As I said, I am not staunchly opposed - while I don't understand the arguments 
given, I don't oppose so long as there is an understanding that this doesn't 
imply any change in our prior agreement re how we handle external RTEs versus 
ORTE and who is maintaining these components.

> 
> That being said, I agree with Ralph on the fact that accepting them in
> the trunk doesn't automatically qualify it for inclusion in any
> further stable release. However, if ORNL setup nightly builds to
> validate their module, I'm pretty certain nothing will stay against
> their inclusion in some future release.

I strongly disagree - we've discussed this at length before, and the issue of 
release schedule coordination is a deal buster. If people think it helpful to 
have their component in the devel trunk, I can somewhat absorb that one. Adding 
them to a release is a non-starter with me.

> 
>  George.
> 
> PS: UTK indirectly uses STCI in other contexts. We would definitively
> appreciate having Open MPI integrate with STCI seamlessly.
> 
> 
> 
> On Tue, May 27, 2014 at 4:18 PM, Thomas Naughton  wrote:
>> Sure, if its helpful I can join a call.
>> 
>> --tjn
>> 
>> 
>> _
>>  Thomas Naughton  naught...@ornl.gov
>>  Research Associate   (865) 576-4184
>> 
>> 
>> On Tue, 27 May 2014, Ralph Castain wrote:
>> 
>>> Forgot to add: would it help to discuss this over the phone instead?
>>> 
>>> 
>>> On May 27, 2014, at 12:56 PM, Ralph Castain  wrote:
>>> 
 
 On May 27, 2014, at 12:50 PM, Edgar Gabriel  wrote:
 
> 
> 
> On 5/27/2014 2:46 PM, Ralph Castain wrote:
>> 
>> 
>> On May 27, 2014, at 12:27 PM, Edgar Gabriel 
>> wrote:
>> 
>>> I'll let ORNL talk about the STCI component itself (which might
>>> have additional reasons), but keeping the code in trunk vs. an
>>> outside github/mercurial repository has two advantages in my
>>> opinion: i) it simplifies the propagation of know-how between the
>>> groups,
>> 
>> 
>> Afraid I don't understand that - this is just glue, right?
> 
> 
> 
> yes, but its easier to look in one place vs. n places for every
> features.
> 
>>> and ii) avoids having to keep a separate branch up to date. (We did
>>> the second part with OMPIO for a couple of years, and that was
>>> really painful).
>> 
>> 
>> Ah, perhaps this is the "rub" - are you saying that you expect us to
>> propagate any changes in the RTE interface to your component? If so,
>> then that violates the original agreement about this framework. It
>> was solely to provide a point-of-interface for *external* groups to
>> connect their RTE's into OMPI. We agreed that we would notify people
>> of changes to that interface, and give them a chance to provide input
>> on those changes - but under no conditions were we wiling to accept
>> responsibility for maintaining those branch interfaces.
>> 
>> Given that the interface is wholly contained in the ompi/rte
>> component, I guess I struggle to understand the code conflict issue.
>> There is no change in the OMPI code base that can possibly conflict
>> with your component. The only things that could impact you are
>> changes in the OMPI layer that require modification to your
>> component, which is something you'd have to do regardless. We will
>> not test nor update that component for you.
> 
> 
> 
> no, not all. My point was that we invested enormous efforts at that time
> to just do the svn merge from the changes on trunk to our branch, that's
> all.
> 
 
 If you are on a branch that contains an svn checkout of the trunk, plus
 one component directory in one framework, then I'm afraid I cannot
 understand how you get merge conflicts. I've been doing this for years and
 haven't hit one yet. The only possible source of a conflict is if I touch
 code that is common to the two repos - i.e., outside of the area that I'm
 adding. In this case, that should never happen, yes?
 
 If it does, then you touched code outside your component, and you either
 (a) are 

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[George Bosilca]

>From a practical perspective, I don't think there is a need for a
phone call. Ralph made his point, and we all took notice of it.
However, the proposed changes are in a single independent component,
with no impact on the rest of the code base. Therefore, there is
absolutely no valid reason not to be accepted in the trunk (ORNL
already signed the contribution agreement). The fact that they are
used by a single institution might be a little unsettling, but we do
have precedents on this area.

That being said, I agree with Ralph on the fact that accepting them in
the trunk doesn't automatically qualify it for inclusion in any
further stable release. However, if ORNL setup nightly builds to
validate their module, I'm pretty certain nothing will stay against
their inclusion in some future release.

  George.

PS: UTK indirectly uses STCI in other contexts. We would definitively
appreciate having Open MPI integrate with STCI seamlessly.



On Tue, May 27, 2014 at 4:18 PM, Thomas Naughton  wrote:
> Sure, if its helpful I can join a call.
>
> --tjn
>
>
>  _
>   Thomas Naughton  naught...@ornl.gov
>   Research Associate   (865) 576-4184
>
>
> On Tue, 27 May 2014, Ralph Castain wrote:
>
>> Forgot to add: would it help to discuss this over the phone instead?
>>
>>
>> On May 27, 2014, at 12:56 PM, Ralph Castain  wrote:
>>
>>>
>>> On May 27, 2014, at 12:50 PM, Edgar Gabriel  wrote:
>>>


 On 5/27/2014 2:46 PM, Ralph Castain wrote:
>
>
> On May 27, 2014, at 12:27 PM, Edgar Gabriel 
> wrote:
>
>> I'll let ORNL talk about the STCI component itself (which might
>> have additional reasons), but keeping the code in trunk vs. an
>> outside github/mercurial repository has two advantages in my
>> opinion: i) it simplifies the propagation of know-how between the
>> groups,
>
>
> Afraid I don't understand that - this is just glue, right?



 yes, but its easier to look in one place vs. n places for every
 features.

>> and ii) avoids having to keep a separate branch up to date. (We did
>> the second part with OMPIO for a couple of years, and that was
>> really painful).
>
>
> Ah, perhaps this is the "rub" - are you saying that you expect us to
> propagate any changes in the RTE interface to your component? If so,
> then that violates the original agreement about this framework. It
> was solely to provide a point-of-interface for *external* groups to
> connect their RTE's into OMPI. We agreed that we would notify people
> of changes to that interface, and give them a chance to provide input
> on those changes - but under no conditions were we wiling to accept
> responsibility for maintaining those branch interfaces.
>
> Given that the interface is wholly contained in the ompi/rte
> component, I guess I struggle to understand the code conflict issue.
> There is no change in the OMPI code base that can possibly conflict
> with your component. The only things that could impact you are
> changes in the OMPI layer that require modification to your
> component, which is something you'd have to do regardless. We will
> not test nor update that component for you.



 no, not all. My point was that we invested enormous efforts at that time
 to just do the svn merge from the changes on trunk to our branch, that's
 all.

>>>
>>> If you are on a branch that contains an svn checkout of the trunk, plus
>>> one component directory in one framework, then I'm afraid I cannot
>>> understand how you get merge conflicts. I've been doing this for years and
>>> haven't hit one yet. The only possible source of a conflict is if I touch
>>> code that is common to the two repos - i.e., outside of the area that I'm
>>> adding. In this case, that should never happen, yes?
>>>
>>> If it does, then you touched code outside your component, and you either
>>> (a) are going to encounter this no matter what because you haven't pushed it
>>> up yet, or (b) couldn't commit that up to the main repo anyway if it
>>> impacted the RTE interface.
>>>
>>> Sorry, but I'm really struggling to understand how adding only this one
>>> component, which you solely modify and control, can possibly help with
>>> maintaining your branch.
>>>
>>>
 Thanks
 Edgar

>
>>
>> In addition, IANAL, but I was actually wandering about the
>> implications of using separate code repositories outside of ompi
>> for sharing code, and whether that is truly still covered by the
>> contributors agreement that we all signed.
>
>
> Of course not - OMPI's license only declares that anything you push
> into the main OMPI code repo (and hence, 

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Thomas Naughton]

Sure, if its helpful I can join a call.

--tjn

 _
  Thomas Naughton  naught...@ornl.gov
  Research Associate   (865) 576-4184


On Tue, 27 May 2014, Ralph Castain wrote:


Forgot to add: would it help to discuss this over the phone instead?


On May 27, 2014, at 12:56 PM, Ralph Castain  wrote:



On May 27, 2014, at 12:50 PM, Edgar Gabriel  wrote:




On 5/27/2014 2:46 PM, Ralph Castain wrote:


On May 27, 2014, at 12:27 PM, Edgar Gabriel 
wrote:


I'll let ORNL talk about the STCI component itself (which might
have additional reasons), but keeping the code in trunk vs. an
outside github/mercurial repository has two advantages in my
opinion: i) it simplifies the propagation of know-how between the
groups,


Afraid I don't understand that - this is just glue, right?



yes, but its easier to look in one place vs. n places for every features.


and ii) avoids having to keep a separate branch up to date. (We did
the second part with OMPIO for a couple of years, and that was
really painful).


Ah, perhaps this is the "rub" - are you saying that you expect us to
propagate any changes in the RTE interface to your component? If so,
then that violates the original agreement about this framework. It
was solely to provide a point-of-interface for *external* groups to
connect their RTE's into OMPI. We agreed that we would notify people
of changes to that interface, and give them a chance to provide input
on those changes - but under no conditions were we wiling to accept
responsibility for maintaining those branch interfaces.

Given that the interface is wholly contained in the ompi/rte
component, I guess I struggle to understand the code conflict issue.
There is no change in the OMPI code base that can possibly conflict
with your component. The only things that could impact you are
changes in the OMPI layer that require modification to your
component, which is something you'd have to do regardless. We will
not test nor update that component for you.



no, not all. My point was that we invested enormous efforts at that time
to just do the svn merge from the changes on trunk to our branch, that's
all.



If you are on a branch that contains an svn checkout of the trunk, plus one 
component directory in one framework, then I'm afraid I cannot understand how 
you get merge conflicts. I've been doing this for years and haven't hit one 
yet. The only possible source of a conflict is if I touch code that is common 
to the two repos - i.e., outside of the area that I'm adding. In this case, 
that should never happen, yes?

If it does, then you touched code outside your component, and you either (a) 
are going to encounter this no matter what because you haven't pushed it up 
yet, or (b) couldn't commit that up to the main repo anyway if it impacted the 
RTE interface.

Sorry, but I'm really struggling to understand how adding only this one 
component, which you solely modify and control, can possibly help with 
maintaining your branch.



Thanks
Edgar





In addition, IANAL, but I was actually wandering about the
implications of using separate code repositories outside of ompi
for sharing code, and whether that is truly still covered by the
contributors agreement that we all signed.


Of course not - OMPI's license only declares that anything you push
into the main OMPI code repo (and hence, our official releases) is
covered by that agreement. Anything you add or distribute externally
is on your own. You can *choose* to license that code in accordance
with the OMPI license, but you aren't *required* to do so.



Anyway, I don't have strong feelings either way as well, just would
see a couple of advantages (for us) if the code was in the trunk.


I'm still trying to understand those - sorry to be a pain, but my
biggest fear at this point is that the perceived advantage is based
on a misunderstanding, and I'd like to head that off before it causes
problems.



Thanks Edgar

On 5/27/2014 1:45 PM, Ralph Castain wrote:

I think so long as we leave these components out of any release,
there is a limited potential for problems (probably most
importantly, we sidestep all the issues about syncing
releases!).

However, that said, I'm not sure what it gains anyone to include
a component that *isn't* going in a release. Nobody outside your
organizations is going to build against it - so what did it
accomplish to push the code into the repo?

Mind you, I'm not saying I'm staunchly opposed - just trying to
understand how it benefits anyone.


On May 27, 2014, at 11:28 AM, Edgar Gabriel 
wrote:


To through in my $0.02, I would see a benefit in adding the
component to the trunk. As I mentioned in the last teleconf, we
are currently working on adding support for the HPX runtime
environment to Open MPI, and for various 

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Thomas Naughton]

Inline comments ... way at the bottom.  ;-)

--tjn

 _
  Thomas Naughton  naught...@ornl.gov
  Research Associate   (865) 576-4184


On Tue, 27 May 2014, Ralph Castain wrote:



On May 27, 2014, at 12:50 PM, Edgar Gabriel  wrote:




On 5/27/2014 2:46 PM, Ralph Castain wrote:


On May 27, 2014, at 12:27 PM, Edgar Gabriel 
wrote:


I'll let ORNL talk about the STCI component itself (which might
have additional reasons), but keeping the code in trunk vs. an
outside github/mercurial repository has two advantages in my
opinion: i) it simplifies the propagation of know-how between the
groups,


Afraid I don't understand that - this is just glue, right?



yes, but its easier to look in one place vs. n places for every features.


and ii) avoids having to keep a separate branch up to date. (We did
the second part with OMPIO for a couple of years, and that was
really painful).


Ah, perhaps this is the "rub" - are you saying that you expect us to
propagate any changes in the RTE interface to your component? If so,
then that violates the original agreement about this framework. It
was solely to provide a point-of-interface for *external* groups to
connect their RTE's into OMPI. We agreed that we would notify people
of changes to that interface, and give them a chance to provide input
on those changes - but under no conditions were we wiling to accept
responsibility for maintaining those branch interfaces.

Given that the interface is wholly contained in the ompi/rte
component, I guess I struggle to understand the code conflict issue.
There is no change in the OMPI code base that can possibly conflict
with your component. The only things that could impact you are
changes in the OMPI layer that require modification to your
component, which is something you'd have to do regardless. We will
not test nor update that component for you.



no, not all. My point was that we invested enormous efforts at that time
to just do the svn merge from the changes on trunk to our branch, that's
all.



If you are on a branch that contains an svn checkout of the trunk, plus one 
component directory in one framework, then I'm afraid I cannot understand how 
you get merge conflicts. I've been doing this for years and haven't hit one 
yet. The only possible source of a conflict is if I touch code that is common 
to the two repos - i.e., outside of the area that I'm adding. In this case, 
that should never happen, yes?

If it does, then you touched code outside your component, and you either (a) 
are going to encounter this no matter what because you haven't pushed it up 
yet, or (b) couldn't commit that up to the main repo anyway if it impacted the 
RTE interface.

Sorry, but I'm really struggling to understand how adding only this one 
component, which you solely modify and control, can possibly help with 
maintaining your branch.



I can't speak for them but know that maintaining our rte/stci component
often requires some attention for changes at different levels.  Most
notably changes APIs related to the modex.

The "glue" code in the ompi-rte interface is generally described in
the comments of rte.h, but in my experience it generally
requires a look at rte/orte/* to know what really changes.   Having a few
different ompi-rte components in the tree seems like it offers a bit more
information about what is required.

It also helps to clarify who's maintaining components when API changes are
proposed that effect the RTE layer.  These are generally announced but
telegraphed but it can be helpful to just see the directories,
reminder about who's paying attention if you see "rte/stci" and "rte/hpx".

Also, to respond to earlier comment.  We will continue to maintain our code
(rte/stci component), but it does simplify the patches/processing we 
maintain for integration with Open-MPI work, i.e., OMPI-trunk +

OMPI-RTE-SCI + STCI.

I'd expect this would be the case for the HPX or other instances.

I thought this was the strength of the component infrastructure.  For
example, the ALPS code is external, but there are alps components in
different frameworks, etc.  And those who care about ALPS test that path.

--tjn




Thanks
Edgar





In addition, IANAL, but I was actually wandering about the
implications of using separate code repositories outside of ompi
for sharing code, and whether that is truly still covered by the
contributors agreement that we all signed.


Of course not - OMPI's license only declares that anything you push
into the main OMPI code repo (and hence, our official releases) is
covered by that agreement. Anything you add or distribute externally
is on your own. You can *choose* to license that code in accordance
with the OMPI license, but you aren't *required* to do so.



Anyway, I don't have strong feelings either way as well, just would
see a 

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Edgar Gabriel]

not really, I stated my case, there is not much more to add. Its up to
the group to decide, and I am fine with any decision.

Edgar

On 5/27/2014 2:57 PM, Ralph Castain wrote:
> Forgot to add: would it help to discuss this over the phone instead?
> 
> 
> On May 27, 2014, at 12:56 PM, Ralph Castain  > wrote:
> 
>>
>> On May 27, 2014, at 12:50 PM, Edgar Gabriel > > wrote:
>>
>>>
>>>
>>> On 5/27/2014 2:46 PM, Ralph Castain wrote:

 On May 27, 2014, at 12:27 PM, Edgar Gabriel >
 wrote:

> I'll let ORNL talk about the STCI component itself (which might
> have additional reasons), but keeping the code in trunk vs. an
> outside github/mercurial repository has two advantages in my
> opinion: i) it simplifies the propagation of know-how between the
> groups,

 Afraid I don't understand that - this is just glue, right?
>>>
>>>
>>> yes, but its easier to look in one place vs. n places for every features.
>>>
> and ii) avoids having to keep a separate branch up to date. (We did
> the second part with OMPIO for a couple of years, and that was
> really painful).

 Ah, perhaps this is the "rub" - are you saying that you expect us to
 propagate any changes in the RTE interface to your component? If so,
 then that violates the original agreement about this framework. It
 was solely to provide a point-of-interface for *external* groups to
 connect their RTE's into OMPI. We agreed that we would notify people
 of changes to that interface, and give them a chance to provide input
 on those changes - but under no conditions were we wiling to accept
 responsibility for maintaining those branch interfaces.

 Given that the interface is wholly contained in the ompi/rte
 component, I guess I struggle to understand the code conflict issue.
 There is no change in the OMPI code base that can possibly conflict
 with your component. The only things that could impact you are
 changes in the OMPI layer that require modification to your
 component, which is something you'd have to do regardless. We will
 not test nor update that component for you.
>>>
>>>
>>> no, not all. My point was that we invested enormous efforts at that time
>>> to just do the svn merge from the changes on trunk to our branch, that's
>>> all.
>>>
>>
>> If you are on a branch that contains an svn checkout of the trunk,
>> plus one component directory in one framework, then I'm afraid I
>> cannot understand how you get merge conflicts. I've been doing this
>> for years and haven't hit one yet. The only possible source of a
>> conflict is if I touch code that is common to the two repos - i.e.,
>> outside of the area that I'm adding. In this case, that should never
>> happen, yes?
>>
>> If it does, then you touched code outside your component, and you
>> either (a) are going to encounter this no matter what because you
>> haven't pushed it up yet, or (b) couldn't commit that up to the main
>> repo anyway if it impacted the RTE interface.
>>
>> Sorry, but I'm really struggling to understand how adding only this
>> one component, which you solely modify and control, can possibly help
>> with maintaining your branch.
>>
>>
>>> Thanks
>>> Edgar
>>>

>
> In addition, IANAL, but I was actually wandering about the
> implications of using separate code repositories outside of ompi
> for sharing code, and whether that is truly still covered by the
> contributors agreement that we all signed.

 Of course not - OMPI's license only declares that anything you push
 into the main OMPI code repo (and hence, our official releases) is
 covered by that agreement. Anything you add or distribute externally
 is on your own. You can *choose* to license that code in accordance
 with the OMPI license, but you aren't *required* to do so.

>
> Anyway, I don't have strong feelings either way as well, just would
> see a couple of advantages (for us) if the code was in the trunk.

 I'm still trying to understand those - sorry to be a pain, but my
 biggest fear at this point is that the perceived advantage is based
 on a misunderstanding, and I'd like to head that off before it causes
 problems.

>
> Thanks Edgar
>
> On 5/27/2014 1:45 PM, Ralph Castain wrote:
>> I think so long as we leave these components out of any release, 
>> there is a limited potential for problems (probably most
>> importantly, we sidestep all the issues about syncing
>> releases!).
>>
>> However, that said, I'm not sure what it gains anyone to include
>> a component that *isn't* going in a release. Nobody outside your 
>> organizations is going to build against it - so what did it 
>> accomplish to push the code into the repo?

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Ralph Castain]

Forgot to add: would it help to discuss this over the phone instead?


On May 27, 2014, at 12:56 PM, Ralph Castain  wrote:

> 
> On May 27, 2014, at 12:50 PM, Edgar Gabriel  wrote:
> 
>> 
>> 
>> On 5/27/2014 2:46 PM, Ralph Castain wrote:
>>> 
>>> On May 27, 2014, at 12:27 PM, Edgar Gabriel 
>>> wrote:
>>> 
 I'll let ORNL talk about the STCI component itself (which might
 have additional reasons), but keeping the code in trunk vs. an
 outside github/mercurial repository has two advantages in my
 opinion: i) it simplifies the propagation of know-how between the
 groups,
>>> 
>>> Afraid I don't understand that - this is just glue, right?
>> 
>> 
>> yes, but its easier to look in one place vs. n places for every features.
>> 
 and ii) avoids having to keep a separate branch up to date. (We did
 the second part with OMPIO for a couple of years, and that was
 really painful).
>>> 
>>> Ah, perhaps this is the "rub" - are you saying that you expect us to
>>> propagate any changes in the RTE interface to your component? If so,
>>> then that violates the original agreement about this framework. It
>>> was solely to provide a point-of-interface for *external* groups to
>>> connect their RTE's into OMPI. We agreed that we would notify people
>>> of changes to that interface, and give them a chance to provide input
>>> on those changes - but under no conditions were we wiling to accept
>>> responsibility for maintaining those branch interfaces.
>>> 
>>> Given that the interface is wholly contained in the ompi/rte
>>> component, I guess I struggle to understand the code conflict issue.
>>> There is no change in the OMPI code base that can possibly conflict
>>> with your component. The only things that could impact you are
>>> changes in the OMPI layer that require modification to your
>>> component, which is something you'd have to do regardless. We will
>>> not test nor update that component for you.
>> 
>> 
>> no, not all. My point was that we invested enormous efforts at that time
>> to just do the svn merge from the changes on trunk to our branch, that's
>> all.
>> 
> 
> If you are on a branch that contains an svn checkout of the trunk, plus one 
> component directory in one framework, then I'm afraid I cannot understand how 
> you get merge conflicts. I've been doing this for years and haven't hit one 
> yet. The only possible source of a conflict is if I touch code that is common 
> to the two repos - i.e., outside of the area that I'm adding. In this case, 
> that should never happen, yes?
> 
> If it does, then you touched code outside your component, and you either (a) 
> are going to encounter this no matter what because you haven't pushed it up 
> yet, or (b) couldn't commit that up to the main repo anyway if it impacted 
> the RTE interface.
> 
> Sorry, but I'm really struggling to understand how adding only this one 
> component, which you solely modify and control, can possibly help with 
> maintaining your branch.
> 
> 
>> Thanks
>> Edgar
>> 
>>> 
 
 In addition, IANAL, but I was actually wandering about the
 implications of using separate code repositories outside of ompi
 for sharing code, and whether that is truly still covered by the
 contributors agreement that we all signed.
>>> 
>>> Of course not - OMPI's license only declares that anything you push
>>> into the main OMPI code repo (and hence, our official releases) is
>>> covered by that agreement. Anything you add or distribute externally
>>> is on your own. You can *choose* to license that code in accordance
>>> with the OMPI license, but you aren't *required* to do so.
>>> 
 
 Anyway, I don't have strong feelings either way as well, just would
 see a couple of advantages (for us) if the code was in the trunk.
>>> 
>>> I'm still trying to understand those - sorry to be a pain, but my
>>> biggest fear at this point is that the perceived advantage is based
>>> on a misunderstanding, and I'd like to head that off before it causes
>>> problems.
>>> 
 
 Thanks Edgar
 
 On 5/27/2014 1:45 PM, Ralph Castain wrote:
> I think so long as we leave these components out of any release, 
> there is a limited potential for problems (probably most
> importantly, we sidestep all the issues about syncing
> releases!).
> 
> However, that said, I'm not sure what it gains anyone to include
> a component that *isn't* going in a release. Nobody outside your 
> organizations is going to build against it - so what did it 
> accomplish to push the code into the repo?
> 
> Mind you, I'm not saying I'm staunchly opposed - just trying to 
> understand how it benefits anyone.
> 
> 
> On May 27, 2014, at 11:28 AM, Edgar Gabriel  
> wrote:
> 
>> To through in my $0.02, I would see a benefit in adding the 
>> component to the trunk. As I mentioned in 

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Ralph Castain]

On May 27, 2014, at 12:50 PM, Edgar Gabriel  wrote:

> 
> 
> On 5/27/2014 2:46 PM, Ralph Castain wrote:
>> 
>> On May 27, 2014, at 12:27 PM, Edgar Gabriel 
>> wrote:
>> 
>>> I'll let ORNL talk about the STCI component itself (which might
>>> have additional reasons), but keeping the code in trunk vs. an
>>> outside github/mercurial repository has two advantages in my
>>> opinion: i) it simplifies the propagation of know-how between the
>>> groups,
>> 
>> Afraid I don't understand that - this is just glue, right?
> 
> 
> yes, but its easier to look in one place vs. n places for every features.
> 
>>> and ii) avoids having to keep a separate branch up to date. (We did
>>> the second part with OMPIO for a couple of years, and that was
>>> really painful).
>> 
>> Ah, perhaps this is the "rub" - are you saying that you expect us to
>> propagate any changes in the RTE interface to your component? If so,
>> then that violates the original agreement about this framework. It
>> was solely to provide a point-of-interface for *external* groups to
>> connect their RTE's into OMPI. We agreed that we would notify people
>> of changes to that interface, and give them a chance to provide input
>> on those changes - but under no conditions were we wiling to accept
>> responsibility for maintaining those branch interfaces.
>> 
>> Given that the interface is wholly contained in the ompi/rte
>> component, I guess I struggle to understand the code conflict issue.
>> There is no change in the OMPI code base that can possibly conflict
>> with your component. The only things that could impact you are
>> changes in the OMPI layer that require modification to your
>> component, which is something you'd have to do regardless. We will
>> not test nor update that component for you.
> 
> 
> no, not all. My point was that we invested enormous efforts at that time
> to just do the svn merge from the changes on trunk to our branch, that's
> all.
> 

If you are on a branch that contains an svn checkout of the trunk, plus one 
component directory in one framework, then I'm afraid I cannot understand how 
you get merge conflicts. I've been doing this for years and haven't hit one 
yet. The only possible source of a conflict is if I touch code that is common 
to the two repos - i.e., outside of the area that I'm adding. In this case, 
that should never happen, yes?

If it does, then you touched code outside your component, and you either (a) 
are going to encounter this no matter what because you haven't pushed it up 
yet, or (b) couldn't commit that up to the main repo anyway if it impacted the 
RTE interface.

Sorry, but I'm really struggling to understand how adding only this one 
component, which you solely modify and control, can possibly help with 
maintaining your branch.


> Thanks
> Edgar
> 
>> 
>>> 
>>> In addition, IANAL, but I was actually wandering about the
>>> implications of using separate code repositories outside of ompi
>>> for sharing code, and whether that is truly still covered by the
>>> contributors agreement that we all signed.
>> 
>> Of course not - OMPI's license only declares that anything you push
>> into the main OMPI code repo (and hence, our official releases) is
>> covered by that agreement. Anything you add or distribute externally
>> is on your own. You can *choose* to license that code in accordance
>> with the OMPI license, but you aren't *required* to do so.
>> 
>>> 
>>> Anyway, I don't have strong feelings either way as well, just would
>>> see a couple of advantages (for us) if the code was in the trunk.
>> 
>> I'm still trying to understand those - sorry to be a pain, but my
>> biggest fear at this point is that the perceived advantage is based
>> on a misunderstanding, and I'd like to head that off before it causes
>> problems.
>> 
>>> 
>>> Thanks Edgar
>>> 
>>> On 5/27/2014 1:45 PM, Ralph Castain wrote:
 I think so long as we leave these components out of any release, 
 there is a limited potential for problems (probably most
 importantly, we sidestep all the issues about syncing
 releases!).
 
 However, that said, I'm not sure what it gains anyone to include
 a component that *isn't* going in a release. Nobody outside your 
 organizations is going to build against it - so what did it 
 accomplish to push the code into the repo?
 
 Mind you, I'm not saying I'm staunchly opposed - just trying to 
 understand how it benefits anyone.
 
 
 On May 27, 2014, at 11:28 AM, Edgar Gabriel  
 wrote:
 
> To through in my $0.02, I would see a benefit in adding the 
> component to the trunk. As I mentioned in the last teleconf, we
> are currently working on adding support for the HPX runtime
> environment to Open MPI, and for various reasons (that I can
> explain if somebody is interested), we think at the moment that
> using the RTE abstraction layer could be 

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Edgar Gabriel]

On 5/27/2014 2:46 PM, Ralph Castain wrote:
> 
> On May 27, 2014, at 12:27 PM, Edgar Gabriel 
> wrote:
> 
>> I'll let ORNL talk about the STCI component itself (which might
>> have additional reasons), but keeping the code in trunk vs. an
>> outside github/mercurial repository has two advantages in my
>> opinion: i) it simplifies the propagation of know-how between the
>> groups,
> 
> Afraid I don't understand that - this is just glue, right?


yes, but its easier to look in one place vs. n places for every features.

>> and ii) avoids having to keep a separate branch up to date. (We did
>> the second part with OMPIO for a couple of years, and that was
>> really painful).
> 
> Ah, perhaps this is the "rub" - are you saying that you expect us to
> propagate any changes in the RTE interface to your component? If so,
> then that violates the original agreement about this framework. It
> was solely to provide a point-of-interface for *external* groups to
> connect their RTE's into OMPI. We agreed that we would notify people
> of changes to that interface, and give them a chance to provide input
> on those changes - but under no conditions were we wiling to accept
> responsibility for maintaining those branch interfaces.
> 
> Given that the interface is wholly contained in the ompi/rte
> component, I guess I struggle to understand the code conflict issue.
> There is no change in the OMPI code base that can possibly conflict
> with your component. The only things that could impact you are
> changes in the OMPI layer that require modification to your
> component, which is something you'd have to do regardless. We will
> not test nor update that component for you.


no, not all. My point was that we invested enormous efforts at that time
to just do the svn merge from the changes on trunk to our branch, that's
all.

Thanks
Edgar

> 
>> 
>> In addition, IANAL, but I was actually wandering about the
>> implications of using separate code repositories outside of ompi
>> for sharing code, and whether that is truly still covered by the
>> contributors agreement that we all signed.
> 
> Of course not - OMPI's license only declares that anything you push
> into the main OMPI code repo (and hence, our official releases) is
> covered by that agreement. Anything you add or distribute externally
> is on your own. You can *choose* to license that code in accordance
> with the OMPI license, but you aren't *required* to do so.
> 
>> 
>> Anyway, I don't have strong feelings either way as well, just would
>> see a couple of advantages (for us) if the code was in the trunk.
> 
> I'm still trying to understand those - sorry to be a pain, but my
> biggest fear at this point is that the perceived advantage is based
> on a misunderstanding, and I'd like to head that off before it causes
> problems.
> 
>> 
>> Thanks Edgar
>> 
>> On 5/27/2014 1:45 PM, Ralph Castain wrote:
>>> I think so long as we leave these components out of any release, 
>>> there is a limited potential for problems (probably most
>>> importantly, we sidestep all the issues about syncing
>>> releases!).
>>> 
>>> However, that said, I'm not sure what it gains anyone to include
>>> a component that *isn't* going in a release. Nobody outside your 
>>> organizations is going to build against it - so what did it 
>>> accomplish to push the code into the repo?
>>> 
>>> Mind you, I'm not saying I'm staunchly opposed - just trying to 
>>> understand how it benefits anyone.
>>> 
>>> 
>>> On May 27, 2014, at 11:28 AM, Edgar Gabriel  
>>> wrote:
>>> 
 To through in my $0.02, I would see a benefit in adding the 
 component to the trunk. As I mentioned in the last teleconf, we
 are currently working on adding support for the HPX runtime
 environment to Open MPI, and for various reasons (that I can
 explain if somebody is interested), we think at the moment that
 using the RTE abstraction layer could be easier for achieving
 what we want to do. That is not at all a judgment on ORTE, but
 a combination of what HPX offers and what we want to achieve
 within that project.
 
 I do not foresee at this point that our component would be 
 production quality or part of an upcoming OMPI release, having 
 however another component in the rte framework  could be
 useful from our point of view. (And yes, the person that asked
 the pmi/rte question on the mailing list was my student who
 tried to make the pmi component work, and was confused about
 the fact that other emails said that the pmi stuff is working,
 while he couldn't even get it to compile :)
 
 Edgar
 
 On 5/27/2014 12:23 PM, Ralph Castain wrote:
> I have mixed thoughts on this request. We have a policy of
> only including things in the code base that are of general
> utility - i.e., that should be generally distributed across
> the community. This component is only applicable to ORNL, and

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Ralph Castain]

On May 27, 2014, at 12:27 PM, Edgar Gabriel  wrote:

> I'll let ORNL talk about the STCI component itself (which might have
> additional reasons), but keeping the code in trunk vs. an outside
> github/mercurial repository has two advantages in my opinion: i) it
> simplifies the propagation of know-how between the groups,

Afraid I don't understand that - this is just glue, right?

> and ii)
> avoids having to keep a separate branch up to date. (We did the second
> part with OMPIO for a couple of years, and that was really painful).

Ah, perhaps this is the "rub" - are you saying that you expect us to propagate 
any changes in the RTE interface to your component? If so, then that violates 
the original agreement about this framework. It was solely to provide a 
point-of-interface for *external* groups to connect their RTE's into OMPI. We 
agreed that we would notify people of changes to that interface, and give them 
a chance to provide input on those changes - but under no conditions were we 
wiling to accept responsibility for maintaining those branch interfaces.

Given that the interface is wholly contained in the ompi/rte component, I guess 
I struggle to understand the code conflict issue. There is no change in the 
OMPI code base that can possibly conflict with your component. The only things 
that could impact you are changes in the OMPI layer that require modification 
to your component, which is something you'd have to do regardless. We will not 
test nor update that component for you.


> 
> In addition, IANAL, but I was actually wandering about the implications
> of using separate code repositories outside of ompi for sharing code,
> and whether that is truly still covered by the contributors agreement
> that we all signed.

Of course not - OMPI's license only declares that anything you push into the 
main OMPI code repo (and hence, our official releases) is covered by that 
agreement. Anything you add or distribute externally is on your own. You can 
*choose* to license that code in accordance with the OMPI license, but you 
aren't *required* to do so.

> 
> Anyway, I don't have strong feelings either way as well, just would see
> a couple of advantages (for us) if the code was in the trunk.

I'm still trying to understand those - sorry to be a pain, but my biggest fear 
at this point is that the perceived advantage is based on a misunderstanding, 
and I'd like to head that off before it causes problems.

> 
> Thanks
> Edgar
> 
> On 5/27/2014 1:45 PM, Ralph Castain wrote:
>> I think so long as we leave these components out of any release,
>> there is a limited potential for problems (probably most importantly,
>> we sidestep all the issues about syncing releases!).
>> 
>> However, that said, I'm not sure what it gains anyone to include a
>> component that *isn't* going in a release. Nobody outside your
>> organizations is going to build against it - so what did it
>> accomplish to push the code into the repo?
>> 
>> Mind you, I'm not saying I'm staunchly opposed - just trying to
>> understand how it benefits anyone.
>> 
>> 
>> On May 27, 2014, at 11:28 AM, Edgar Gabriel 
>> wrote:
>> 
>>> To through in my $0.02, I would see a benefit in adding the
>>> component to the trunk. As I mentioned in the last teleconf, we are
>>> currently working on adding support for the HPX runtime environment
>>> to Open MPI, and for various reasons (that I can explain if
>>> somebody is interested), we think at the moment that using the RTE
>>> abstraction layer could be easier for achieving what we want to do.
>>> That is not at all a judgment on ORTE, but a combination of what
>>> HPX offers and what we want to achieve within that project.
>>> 
>>> I do not foresee at this point that our component would be
>>> production quality or part of an upcoming OMPI release, having
>>> however another component in the rte framework  could be useful
>>> from our point of view. (And yes, the person that asked the pmi/rte
>>> question on the mailing list was my student who tried to make the
>>> pmi component work, and was confused about the fact that other
>>> emails said that the pmi stuff is working, while he couldn't even
>>> get it to compile :)
>>> 
>>> Edgar
>>> 
>>> On 5/27/2014 12:23 PM, Ralph Castain wrote:
 I have mixed thoughts on this request. We have a policy of only 
 including things in the code base that are of general utility -
 i.e., that should be generally distributed across the community.
 This component is only applicable to ORNL, and it would therefore
 seem more sensible to have it continue to be maintained there.
 
 I'm unaware of anyone outside of ORNL that regularly tests for 
 ompi-rte abstraction violations, and I suspect that your
 internal tests are the right place for catching them as nobody
 else really seems to care. It isn't clear to me how adding this
 component directly to the general code base impacts that

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Edgar Gabriel]

I'll let ORNL talk about the STCI component itself (which might have
additional reasons), but keeping the code in trunk vs. an outside
github/mercurial repository has two advantages in my opinion: i) it
simplifies the propagation of know-how between the groups, and ii)
avoids having to keep a separate branch up to date. (We did the second
part with OMPIO for a couple of years, and that was really painful).

In addition, IANAL, but I was actually wandering about the implications
of using separate code repositories outside of ompi for sharing code,
and whether that is truly still covered by the contributors agreement
that we all signed.

Anyway, I don't have strong feelings either way as well, just would see
a couple of advantages (for us) if the code was in the trunk.

Thanks
Edgar

On 5/27/2014 1:45 PM, Ralph Castain wrote:
> I think so long as we leave these components out of any release,
> there is a limited potential for problems (probably most importantly,
> we sidestep all the issues about syncing releases!).
> 
> However, that said, I'm not sure what it gains anyone to include a
> component that *isn't* going in a release. Nobody outside your
> organizations is going to build against it - so what did it
> accomplish to push the code into the repo?
> 
> Mind you, I'm not saying I'm staunchly opposed - just trying to
> understand how it benefits anyone.
> 
> 
> On May 27, 2014, at 11:28 AM, Edgar Gabriel 
> wrote:
> 
>> To through in my $0.02, I would see a benefit in adding the
>> component to the trunk. As I mentioned in the last teleconf, we are
>> currently working on adding support for the HPX runtime environment
>> to Open MPI, and for various reasons (that I can explain if
>> somebody is interested), we think at the moment that using the RTE
>> abstraction layer could be easier for achieving what we want to do.
>> That is not at all a judgment on ORTE, but a combination of what
>> HPX offers and what we want to achieve within that project.
>> 
>> I do not foresee at this point that our component would be
>> production quality or part of an upcoming OMPI release, having
>> however another component in the rte framework  could be useful
>> from our point of view. (And yes, the person that asked the pmi/rte
>> question on the mailing list was my student who tried to make the
>> pmi component work, and was confused about the fact that other
>> emails said that the pmi stuff is working, while he couldn't even
>> get it to compile :)
>> 
>> Edgar
>> 
>> On 5/27/2014 12:23 PM, Ralph Castain wrote:
>>> I have mixed thoughts on this request. We have a policy of only 
>>> including things in the code base that are of general utility -
>>> i.e., that should be generally distributed across the community.
>>> This component is only applicable to ORNL, and it would therefore
>>> seem more sensible to have it continue to be maintained there.
>>> 
>>> I'm unaware of anyone outside of ORNL that regularly tests for 
>>> ompi-rte abstraction violations, and I suspect that your
>>> internal tests are the right place for catching them as nobody
>>> else really seems to care. It isn't clear to me how adding this
>>> component directly to the general code base impacts that
>>> operation. The original PMI component in the ompi/rte framework
>>> wasn't intended to provide an alternative method for building
>>> OMPI - it was solely created to support the development of that
>>> framework and had no intended utility beyond that time (hence the
>>> RFC to remove it to avoid user confusion as we just saw on the
>>> user mailing list).
>>> 
>>> 
>>> On May 27, 2014, at 9:25 AM, Thomas Naughton
>>>  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  naught...@ornl.gov
 Research Associate   (865) 
 576-4184
 
 ___ devel mailing
 list de...@open-mpi.org 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
>>>
>>>
 
___ devel mailing list
>>> de...@open-mpi.org Subscription: 
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this
>>> post: 
>>> 

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Ralph Castain]

I think so long as we leave these components out of any release, there is a 
limited potential for problems (probably most importantly, we sidestep all the 
issues about syncing releases!).

However, that said, I'm not sure what it gains anyone to include a component 
that *isn't* going in a release. Nobody outside your organizations is going to 
build against it - so what did it accomplish to push the code into the repo?

Mind you, I'm not saying I'm staunchly opposed - just trying to understand how 
it benefits anyone.


On May 27, 2014, at 11:28 AM, Edgar Gabriel  wrote:

> To through in my $0.02, I would see a benefit in adding the component to
> the trunk. As I mentioned in the last teleconf, we are currently working
> on adding support for the HPX runtime environment to Open MPI, and for
> various reasons (that I can explain if somebody is interested), we think
> at the moment that using the RTE abstraction layer could be easier for
> achieving what we want to do. That is not at all a judgment on ORTE, but
> a combination of what HPX offers and what we want to achieve within that
> project.
> 
> I do not foresee at this point that our component would be production
> quality or part of an upcoming OMPI release, having however another
> component in the rte framework  could be useful from our point of view.
> (And yes, the person that asked the pmi/rte question on the mailing list
> was my student who tried to make the pmi component work, and was
> confused about the fact that other emails said that the pmi stuff is
> working, while he couldn't even get it to compile :)
> 
> Edgar
> 
> On 5/27/2014 12:23 PM, Ralph Castain wrote:
>> I have mixed thoughts on this request. We have a policy of only
>> including things in the code base that are of general utility - i.e.,
>> that should be generally distributed across the community. This
>> component is only applicable to ORNL, and it would therefore seem
>> more sensible to have it continue to be maintained there.
>> 
>> I'm unaware of anyone outside of ORNL that regularly tests for
>> ompi-rte abstraction violations, and I suspect that your internal
>> tests are the right place for catching them as nobody else really
>> seems to care. It isn't clear to me how adding this component
>> directly to the general code base impacts that operation. The
>> original PMI component in the ompi/rte framework wasn't intended to
>> provide an alternative method for building OMPI - it was solely
>> created to support the development of that framework and had no
>> intended utility beyond that time (hence the RFC to remove it to
>> avoid user confusion as we just saw on the user mailing list).
>> 
>> 
>> On May 27, 2014, at 9:25 AM, Thomas Naughton 
>> 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  naught...@ornl.gov
>>> Research Associate   (865)
>>> 576-4184
>>> 
>>> ___ devel mailing list 
>>> de...@open-mpi.org 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
>> 
>> ___ devel mailing list 
>> de...@open-mpi.org Subscription:
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/05/14854.php
>> 
> 
> -- 
> Edgar Gabriel
> Associate Professor
> Parallel Software Technologies Lab  http://pstl.cs.uh.edu
> Department of Computer Science  University of Houston
> Philip G. Hoffman Hall, Room 524Houston, TX-77204, USA
> Tel: +1 (713) 743-3857  Fax: +1 (713) 743-3335
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/05/14856.php

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Edgar Gabriel]

To through in my $0.02, I would see a benefit in adding the component to
the trunk. As I mentioned in the last teleconf, we are currently working
on adding support for the HPX runtime environment to Open MPI, and for
various reasons (that I can explain if somebody is interested), we think
at the moment that using the RTE abstraction layer could be easier for
achieving what we want to do. That is not at all a judgment on ORTE, but
a combination of what HPX offers and what we want to achieve within that
project.

I do not foresee at this point that our component would be production
quality or part of an upcoming OMPI release, having however another
component in the rte framework  could be useful from our point of view.
(And yes, the person that asked the pmi/rte question on the mailing list
was my student who tried to make the pmi component work, and was
confused about the fact that other emails said that the pmi stuff is
working, while he couldn't even get it to compile :)

Edgar

On 5/27/2014 12:23 PM, Ralph Castain wrote:
> I have mixed thoughts on this request. We have a policy of only
> including things in the code base that are of general utility - i.e.,
> that should be generally distributed across the community. This
> component is only applicable to ORNL, and it would therefore seem
> more sensible to have it continue to be maintained there.
> 
> I'm unaware of anyone outside of ORNL that regularly tests for
> ompi-rte abstraction violations, and I suspect that your internal
> tests are the right place for catching them as nobody else really
> seems to care. It isn't clear to me how adding this component
> directly to the general code base impacts that operation. The
> original PMI component in the ompi/rte framework wasn't intended to
> provide an alternative method for building OMPI - it was solely
> created to support the development of that framework and had no
> intended utility beyond that time (hence the RFC to remove it to
> avoid user confusion as we just saw on the user mailing list).
> 
> 
> On May 27, 2014, at 9:25 AM, Thomas Naughton 
> 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  naught...@ornl.gov
>> Research Associate   (865)
>> 576-4184
>> 
>> ___ devel mailing list 
>> de...@open-mpi.org 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
> 
> ___ devel mailing list 
> de...@open-mpi.org Subscription:
> http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/05/14854.php
> 

-- 
Edgar Gabriel
Associate Professor
Parallel Software Technologies Lab  http://pstl.cs.uh.edu
Department of Computer Science  University of Houston
Philip G. Hoffman Hall, Room 524Houston, TX-77204, USA
Tel: +1 (713) 743-3857  Fax: +1 (713) 743-3335



signature.asc
Description: OpenPGP digital signature

Re: [OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Ralph Castain]

I have mixed thoughts on this request. We have a policy of only including 
things in the code base that are of general utility - i.e., that should be 
generally distributed across the community. This component is only applicable 
to ORNL, and it would therefore seem more sensible to have it continue to be 
maintained there.

I'm unaware of anyone outside of ORNL that regularly tests for ompi-rte 
abstraction violations, and I suspect that your internal tests are the right 
place for catching them as nobody else really seems to care. It isn't clear to 
me how adding this component directly to the general code base impacts that 
operation. The original PMI component in the ompi/rte framework wasn't intended 
to provide an alternative method for building OMPI - it was solely created to 
support the development of that framework and had no intended utility beyond 
that time (hence the RFC to remove it to avoid user confusion as we just saw on 
the user mailing list).


On May 27, 2014, at 9:25 AM, Thomas Naughton  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  naught...@ornl.gov
>  Research Associate   (865) 576-4184
> 
> ___
> devel mailing list
> de...@open-mpi.org
> 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

[OMPI devel] RFC: add STCI component to OMPI/RTE framework

[Thomas Naughton]

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  naught...@ornl.gov
  Research Associate   (865) 576-4184