I think Brian's point is that it should be a SVN branch.
On Oct 29, 2013, at 3:27 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > Hi, > 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 > Mike. > > > On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W <bwba...@sandia.gov> 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 > > -- > Brian W. Barrett > Scalable System Software Group > Sandia National Laboratories > > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
