I think the community’s concerns are valid. What Mike is articulating is that we already maintain a “1.7 ready” OSHMEM branch internally. I think it should be a simple procedure to do as Brian and Ralph are suggesting and branch off of 1.7 in SVN and apply our patches. We can do this.
Yes, what's important is that 1) we all have a way to review the final merge (which means a public branch) and 2) it's easy for the GK to merge.
Sent with Good (www.good.com)
From: Jeff Squyres (jsquyres) [email@example.com]
Sent: Tuesday, October 29, 2013 04:36 AM Mountain Standard Time
To: Open MPI Developers
Subject: [EXTERNAL] Re: [OMPI devel] SHMEM v1.7 merge proposal
I think Brian's point is that it should be a SVN branch.
On Oct 29, 2013, at 3:27 AM, Mike Dubman <firstname.lastname@example.org> wrote:
> This is exactly the way we handle it now. We have internal branch on top of v1.7 with all SHMEM code in it.
> It runs mtt and other tests.
> Once we done with all changes - we will provide patch (and branch direct access if needed) for GK.
> Kind Regards
> On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W <email@example.com> wrote:
> All -
> Ralph and I talked today about the logistics of bringing the OpenSHMEM
> code to the 1.7 release branch, as it's now a fairly large set of changes
> from the trunk. What we propose is to follow the same proceedure we used
> when merging in the RTE framework change, which is essentially a staging
> branch. So, Mellanox (as the one filing the CMR) would branch from 1.7,
> bring the OpenSHMEM changes into that (and hopefully test), and then file
> a single CMR for the changes from the branch. If done properly, the GK
> then only has to merge with --reintegrate and we're set.
> Let's talk about it on the call tomorrow, but that's the current proposal.
> Brian W. Barrett
> Scalable System Software Group
> Sandia National Laboratories
> devel mailing list
> devel mailing list
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
devel mailing list