[ewg] Compatibility in OFED

Sasha Khapyorsky sashak at voltaire.com
Mon Jun 2 15:04:56 PDT 2008


On 14:22 Mon 02 Jun     , Betsy Zeller wrote:
> Sasha - one of the things we discussed at the Sonoma conference was
> evolving our development process to emphasize the "Enterprise" in "Open
> Fabrics Enterprise Distribution". Part of that is minimizing disruption
> when new versions of OFED are installed. We want customers to feel
> comfortable upgrading to new versions of OFED, and that's not going to
> be true if they get surprised by other (previously working) software
> breaking after installation. 

I agree, but libosmcomp is not good example. Unlike another libs it was
never declared as "public", never had documented API, and actually even
not packaged (as management tarball). Instead its primary goal was
internal use by OpenSM and ibutils.

Somebody decided to use it for something else. That is fine. Obviously
she/he will need to care about compatibility, to track the changes
(which are public) or at least to let us know about such uses.

> What John is asking for here (at least deliver both versions of the
> library for some period of time, and preferably don't break backward
> compatibility at all) seems pretty reasonable from the user's
> perspective, though I acknowledge that actually doing this requires
> extra effort.

What you are asking is to change the status of this library. It can be
discussed and a criteria should be defined. Probably it is enough to
have separate 'ofed-1.x-compat' package with such sort of things (old
libraries, etc.).

> Separately, we should discuss how me manage version changes -
> introducing a version change in the middle of the RCs seems a bit late
> in the process.

I agree that number of changes (at all) should be minimized in RC
period.

Sasha



More information about the ewg mailing list