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

[Sasha Khapyorsky]

On 17:04 Wed 17 Jan     , Jeff Squyres wrote:
> 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.

But when they do change we update the version and create new binary
file - bin-file-ver2.1 .

> >>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. 

Right, it is source packaging results - similar meaning.

> 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.

This is tracked in fetch/build scripts, and it is under version control.
External packages can be hosted (or just copyed) on the OFA site.

> 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).

Only if we are going to change such files, but I guess in our case we
are not - instead we will create new package files with new versions.

Sasha