[openib-general] OpenSM Issues of the last couple days

[Sasha Khapyorsky]

On 18:42 Fri 08 Dec     , Eitan Zahavi wrote:
> Hal Rosenstock wrote:
> >Hi Eitan,
> >
> >Just wanted to close the loop on the OpenSM issues of the last couple
> >days.
> >
> >1. When can you supply an OpenSM verbose log for the InformInfo
> >subscribe problem you reported earlier today ? Failing that, I don't
> >know how to reproduce this.
> >  
> Attached
> >2. With the latest tree, do your simulation tests now work ? The
> >osm.fdbs UNREACHABLE was only a problem with the file and not with the
> >LFTs in the network.
> >  
> Yes they do.
> >3. In terms of file format changes, the lack of any file versioning
> >makes it difficult to move these forward when the need arises. (The
> >format change to osm.mcfdbs was unintentional (not by design)).
> >  
> The issues until now were not that a file format change was required but 
> were unintentional.
> When we will have a real need to change file format I am sure we can 
> agree on adding version and change all parsers.
> >4. I encourage you to look at and comment on the OpenSM patches rather
> >than waiting for them to be in the tree.
> >  
> I am sure you did not mean to, but now I have to admit my limited skills 
> in catching bugs by reading patches :-( .
> Instead on relying on bug reading I use automatic regression. I wish we 
> could agree on some regression that
> each developer will have to run before patches are committed to the trunk.
> On my side I would love to have an automatic way to include all the 
> patches posted (one at a time) run "dead or alive" check
> and provide feedback. Currently my automation is limited to testing the 
> trunk. So I will always be complaining after the patches are
> committed. I think this is the way most other components testing works.
> 
> What kind of regression suite do you and Sasha use?

On my side it clearly depends from kind of changes. In general I would
call this "uni-testing".

> Can we agree on minimal pre-commit testing?
> Can we have a branch for that sake where all patches will first have to 
> go into for 2 days? (it will allow for pre-trunk testing).

One more development branch? Will you test (or even see) this? If so I
can publish the "fresh" tree.

Sasha