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
