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

[Hal Rosenstock]

On Tue, 2006-12-26 at 15:01, Michael S. Tsirkin wrote:
> > > > 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.

That's fine with me but not what a previous email said (in terms of
updating the sources) and what has been followed for OpenSM at least
until now...

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

This has been agreed to and will be done before 1/31 for OFED 1.2.

-- Hal

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