How are you going to more effectively transition codes between 1.7 and 1.9 than from internal code to external code? Decisions made by Mellanox internally should not negatively impact the community code base.
Brian On 10/28/13 1:48 PM, "Mike Dubman" <mi...@dev.mellanox.co.il> wrote: >pgas/shmem on top of OMPI 1.6 eixtsts for ~1year as internal mellanox >tree with customer base and set of applications using shmem* friends. > > >we are in process of droping shmem* friends and using osh* ones in >internal codes, but for some codes it will take time to transit. > > > >It would help us to maintain better transition support if both names will >be available for some defined period of time. > > >Thanks > > > > > >On Mon, Oct 28, 2013 at 9:13 PM, Barrett, Brian W ><bwba...@sandia.gov> wrote: > >What's the advantage of that approach? You're adding legacy baggage to an >unreleased product, which does not seem like good development practice. >Or, put it another way, one of the 1.7 Release Managers can't see a reason >that we should bring shmemcc and friends into 1.7, so convince me. > >Brian > >On 10/28/13 1:08 PM, "Mike Dubman" <mi...@dev.mellanox.co.il> wrote: > >>I would prefer to keep both names for a while and depricate them >>gradually. >>I suggest to release 1st drop with both namings and drop legacy right >>after that. >> >> >> >> >>On Mon, Oct 28, 2013 at 8:22 PM, Barrett, Brian W >><bwba...@sandia.gov> wrote: >> >>I'm not sure what we gain by having them. It's a new (to us) product; >>let's not support legacy names. >> >>Brian >> >>On 10/28/13 11:40 AM, "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> >>wrote: >> >>>Ah -- my mistake in the original post: I now see that it installs *both* >>>shmemcc and oshcc (and friends). I didn't notice the osh* versions in >>>my >>>initial post. >>> >>>The question still remains, though -- do we still want these names >>>installed: >>> >>>----- >>>$ cd $prefix/bin >>>$ ls -1 shmem* >>>shmemcc@ >>>shmemfort@ >>>shmemrun@ >>>----- >>> >>> >>>On Oct 28, 2013, at 1:03 PM, Mike Dubman <mi...@dev.mellanox.co.il> >>> wrote: >>> >>>> Thanks Brian, >>>> The code in trunk already generates: >>>> >>>> oshcc oshfort oshmem_info oshrun >>>> >>>> >>>> On Sat, Oct 26, 2013 at 12:13 AM, Barrett, Brian W >>>><bwba...@sandia.gov> >>>>wrote: >>>> i thought I mentioned this before, but the compilers should be oshcc, >>>>oshCC, and oshfort, with the starter named oshrun, according to >>>>Appendix >>>>C of the spec. >>>> >>>> Brian >>>> >>>> -- >>>> Brian W. Barrett >>>> Scalable System Software Group >>>> Sandia National Laboratories >>>> ________________________________________ >>>> From: devel [devel-boun...@open-mpi.org] on behalf of Jeff Squyres >>>>(jsquyres) [jsquy...@cisco.com] >>>> Sent: Friday, October 25, 2013 3:32 PM >>>> To: Open MPI Developers >>>> Subject: [EXTERNAL] Re: [OMPI devel] shmem vs. oshmem >>>> >>>> On Oct 25, 2013, at 12:58 PM, Igor Ivanov <igor.iva...@itseez.com> >>>>wrote: >>>> >>>> >> - shmemcc / shmemfort / shmem_info / shmemrun >>>> >> --> should these all be "oshmem*" ? >>>> >> >>>> >> - the examples are hello_shmem* and ring_shmem* >>>> >> --> should these all be "*_oshmem*" ? >>>> > These examples are not OpenSHMEM specific. >>>> >> >>>> >> - there are header files named shmem* >>>> >> --> I'm guessing the names "shmem.h" and "shmem.fh" are mandated >>>> > OpenSHMEM specification says >>>> >>>> So ya, those names are standardized -- no problem. >>>> >>>> But shouldn't we be branding everything else as oshmem? Even if the >>>>examples are not oshmem-specific. >>>> >>>> We're shipping oshmem, not shmem, so why not call them oshmem examples >>>>[that also happen to be shmem examples] -- rather than shmem examples >>>>[that also happen to be oshmem examples]? >>>> >>>> -- >>>> Jeff Squyres >>>> jsquy...@cisco.com >>>> For corporate legal information go to: >>>>http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> >>>> _______________________________________________ >>>> devel mailing list >>>> de...@open-mpi.org >>>> >http://www.open-mpi.org/mailman/listinfo.cgi/devel ><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 ><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 ><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/ >>> >>>_______________________________________________ >>>devel mailing list >>>de...@open-mpi.org >>>http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >> >> >>-- >> 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 >> >> >> >> >> >> >> >> > > >-- > 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 > > > > > > > > -- Brian W. Barrett Scalable System Software Group Sandia National Laboratories
