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 <gabriel_at_[hidden]> 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
> 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 :)
> 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 <naughtont_at_[hidden]>
>>> WHAT: add new component to ompi/rte framework
>>> WHY: because it will simplify our maintenance & provide an alt.
>>> 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 Naughton naughtont_at_[hidden]
>>> Research Associate (865)
>>> _______________________________________________ devel mailing list
>>> devel_at_[hidden] Subscription:
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this
>> _______________________________________________ devel mailing list
>> devel_at_[hidden] Subscription:
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this post:
> 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 524 Houston, TX-77204, USA
> Tel: +1 (713) 743-3857 Fax: +1 (713) 743-3335
> devel mailing list
> 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