[openfabrics-ewg] [PATCH] osm:Fix PathRecord bug in using MTU/rate/PktLife explicitly ignoring selectors

[Michael S. Tsirkin]

> > > Should this be applied for OFED 1.1 as well ?
> > 
> > There are a lot of other fixes all over the stack that might be
> > useful to people.
> > But first EWG needs to decide how OFED 1.1 support will be done.
> 
> I thought that was already decided. Tziporet indicated to do this a
> while ago (post 1.1 "ship").

The support page. Yes. But not for new SRPMs.

> > For now, the only thing we have is the support wiki with links
> > to patches. So if there's a customer that is hit by one
> > of these bugs, a patch should be created and put here,
> > and description added to wiki.
> 
> Yes and the sources updated as well just in case a new SRPM is
> created...

That's the big question. Suppose someone decides there's a
show-stopper he wants fixed (like ehca guys had) and wants to build
a bugfix release. This entity might not care about or use opensm,
but since you checked stuff into branch, a version of opensm that
was not properly QA'd will get dropped in this dot release.
It would have been better to stick with the QA'd code from 1.1.

So what I am saying, *when* there's a release the person(s)
that do it should decide changes in which packages do they want.

All this stems from the model we had for OFED, where
we have a global "BUILD ID" and a monolitic package
instead of a set of modules which can be updated individually.

Hopefully maintainers (besides Roland that is) will finally
start making releases of packages, then OFED will package
them together but user will be later able to update some package
separately. This clearly applies to userspace libraries,
and maybe for kernel modules we can also invent something like this too,
so that e.g. ehca module can be updated without risking breaking
mthca.

-- 
MST