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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
