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 <naught...@ornl.gov> 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
