not really, I stated my case, there is not much more to add. Its up to the group to decide, and I am fine with any decision.
Edgar On 5/27/2014 2:57 PM, 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 > <mailto:r...@open-mpi.org>> wrote: > >> >> On May 27, 2014, at 12:50 PM, Edgar Gabriel <gabr...@cs.uh.edu >> <mailto: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 >>>> <mailto: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 >>>>>> <mailto: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 <mailto: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 >>> <mailto:naught...@ornl.gov> >>>>>>>>> Research Associate (865) >>>>>>>>> 576-4184 >>>>>>>>> >>>>>>>>> _______________________________________________ devel >>>>>>>>> mailing list de...@open-mpi.org >>>>>>>>> <mailto: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 <mailto: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 >>>>>>> <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 <mailto: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 <mailto: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 <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 <mailto: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 <mailto: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 >>> <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 <mailto: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/14863.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
