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 >
