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 <gabr...@cs.uh.edu> 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 <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 >> >> _______________________________________________ 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 524 Houston, 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
