[openfabrics-ewg] [openib-general] Reminder: OFED 1.2

[Jeff Squyres]

On Jan 17, 2007, at 5:02 PM, Sasha Khapyorsky wrote:

>> 1. Putting the MPI release in git provides a level of OFED-specific
>> history and version control.  This was explicitly stated on the call
>> yesterday.
>
> Which history information we are expecting to see between bin-file- 
> ver1
> and bin-file-ver2, where files bin-file-ver* are never changed?

I think the point is when they *do* change.

>> 2. MPI's have concrete "releases" to OFED just like all other ULP's,
>> especially if there is any OFED-specific packaging involved in the
>> MPI's release.  This was not stated on the call, but it makes sense
>> to me.
>>
>> 3. Putting everything in git makes it nicely uniform for OFED to be
>> assembled.  This was not stated on the call, and I'm sure it's not a
>> requirement, but it is a little nice to be uniform when assembling
>> OFED (my $0.02).
>>
>> 4. We used to put the MPI releases in SVN (tarball or SRPM) for prior
>> OFED release processes,
>
> Yes, and it was bad practice IMO. GIT and SVN are version tracking  
> tools,
> mostly usable for sources and not for compilation results. Why one
> should install git if everything really needed is just to download  
> file
> from the server?

The SRPMs are not compilation results.  Putting compilation results  
in a version tracking tool would be useless, I agree.

>> so putting them in a git seems to parallel
>> that procedure.
>
> Just file hosting should be perfectly enough for the all above. I  
> don't
> see any real reason to use git as non-versioned binary files storage.

I think the point was that you could then get a definitive set of  
files that were shipped in OFED version x.y -- you could accurately  
rebuild OFED regardless of what files are hosted on the other open  
source web sites.  A perfect example is that the MVAPICH1 package in  
OFED is prepared by Mellanox, not OSU.  So there was no web site to  
make that tarball and support files available from.  Another example  
is that open source projects may decide to no longer host older  
versions of their software -- OFA may not be able to control that.

The point here is that version control principles apply to binaries  
just as well as they apply to sources (indeed, the files we're  
talking about here are binary bundles of sources).

Just my $0.02.  :-)

-- 
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems