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
