[ofw] RE: OpenSM 3.3.3 available for interested parties.

[Leonid Keller]

SEE INLINE 

> -----Original Message-----
> From: Sean Hefty [mailto:sean.hefty at intel.com] 
> Sent: Thursday, November 05, 2009 1:34 AM
> To: Smith, Stan; Leonid Keller
> Cc: ofw at lists.openfabrics.org
> Subject: RE: OpenSM 3.3.3 available for interested parties.
> 
> >I'd like to propose the following svn src file structure 
> changes until 
> >the WinOF 2.3 time frame.
> >
> > trunk\ulp\opensm\user --> trunk\ulp\opensm\userO 
> > branches\opensm_3\user --> trunk\ulp\opensm\user
> >
> >Now we have
> >    trunk\ulp\opensm\userO              current opensm 
> version @ 3.0.0 base.
> >    trunk\ulp\opensm\user               New opensm version # 3.3.3
> >
> >Additionally the SOURCES files in the 
> trunk\ulp\opensm\userO\* would be 
> >modified to append the letter 'O' to the .exe filename to 
> distinguish 
> >them from new version; examples:
> >  opensmO.exe
> >  osmtestO.exe
> >  ibtrapgenO.exe
> >
> >This could be abbreviated to just building opensmo.exe.
> >
> >With the new 3.3.3 version of openSM the diffs between the 
> latest OFED 
> >(3.3.3) and the Windows version are not so overwhelming and can be 
> >managed in place; point being the trunk\ulp\opensm\userO is a 
> >life-saver until full confidence is gained in the new opensm 
> implementation.
> >
> >Your thoughts?
> 
> Egads, no.  If someone wants an old version of an executable, 
> they can download that specific version.  If someone needs 
> old version of source code, that's why we use a source 
> repository.  SVN already supports checking out a previous 
> commit and using branches.  Delete trunk\ulp\opensm (make a 
> branch first if desired) and drop the new code in 
> trunk\tools\opensm, where it probably should have gone 
> originally.  If you want to package multiple versions of 
> opensm in some distribution, that's fine, but don't rename 
> the executable.  It's confusing and breaks any shortcuts or 
> scripts which may reference the program.  If the new version 
> of opensm is not ready, then keep it in a branch.

I think, to put new Opensm under trunk\tools\opensm is a good idea,
But I wouldn't delete the current branch till we distribute the old
executables.
I'd suggest to change the target destination so as old Opensm
executables would be placed somewhere under ulp\opensm\bin and with the
same names as Sean suggest.
Then on the installation phase they can be copied under new opensm_3_0_0
folder.
I don't think we may ask customers to check out old Opensm and to build
on their own.
I don't think we can test that complicate program as opensm enough as to
be sure that it will work not worse than the previous one in all
situations.
I'd like first to see the new Opensm, working in real big clusters.

 
> 
> - Sean
> 
>