>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 <naught...@ornl.gov> 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 <r...@open-mpi.org> wrote: >> >>> >>> On May 27, 2014, at 12:50 PM, Edgar Gabriel <gabr...@cs.uh.edu> wrote: >>> >>>> >>>> >>>> On 5/27/2014 2:46 PM, Ralph Castain wrote: >>>>> >>>>> >>>>> On May 27, 2014, at 12:27 PM, Edgar Gabriel <gabr...@cs.uh.edu> >>>>> 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 <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 >>>>>> >>>>>> _______________________________________________ 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/14858.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/14859.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/14860.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/14866.php
