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 <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 > > _______________________________________________ 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/14857.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
signature.asc
Description: OpenPGP digital signature
