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

[Hal Rosenstock]

On Tue, 2006-12-12 at 02:10, Eitan Zahavi wrote:
> Hal Rosenstock wrote:
> > On Sat, 2006-12-09 at 09:35, Eitan Zahavi wrote:
> >   
> >> Hal Rosenstock wrote:
> >>     
> >>> On Fri, 2006-12-08 at 11:42, 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
> >>>>     
> >>>>         
> >> I will need to look into it in greater details. Might be a simulator flow issue. But I am not sure.
> >>     
> >
> > Any idea on when you will have a chance to look into this ?
> >   
> Maybe by the weekend.
> >   
> >>>>> 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 :-( .
> >>>>     
> >>>>         
> >>> Not just read, but they are there to try out as well.
> >>>   
> >>>       
> >> I will need an automatic flow for that sake. I can not keep up with the 
> >> amount of patches manually.
> >> But I do not know how to automatically convert the mails into patches 
> >> into a tree.
> >>     
> >>> You could try out the patches and do the same thing before they are
> >>> committed.
> >>>
> >>>   
> >>>       
> >> I have automation based on the committed tree that pull it (git trem) , 
> >> compile and run regression.
> >> Actually this is how all other code is handled too.
> >>     
> >
> > Are you referring to OFED ?
> >   
> No the current GIT tree under 
> git://staging.openfabrics.org/~halr/management.git

OK but I was commenting on what you said about "all other code" being
handled this way.

> > In the case of OFED, where do those "special" trees/branches come from ?
> >   
> No. I think we are having some miss-understanding:
> I am not proposing using a pre-commit branch.
> But if there is no such branch I can not do pre-commit testing.

Understood.

> I think it is fine to have post-commit bug reports. No big deal.

Right; rather than "pre trunk commit" ones. If it breaks, we try to fix
it as fast as possible or perhaps even back out the change if there is
some critical reason to do so.

> We branch when we go to an OFED release.

Yes.

> Then I have two regressions run every night. One on the trunk and one on 
> the OFED branch.
> This is how things were for OFED1.1 and OFED1.0.

That would be great.

> It is your call if we need to have a "stable" trunk and experimental  
> branch such that I will be able to test pre-trunk patches.

I'll consider this based on how stable or unstable the trunk is as we go
forward but still prefer to not have to maintain another branch (for
obvious reasons).

> What I will not be able to do is to have an automatic system to select 
> which patches to include in the regression, etc etc.

OK.

-- Hal

> Eitan
> > -- Hal
> >
> >
> >
> > _______________________________________________
> > openib-general mailing list
> > openib-general at openib.org
> > http://openib.org/mailman/listinfo/openib-general
> >
> > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
> >   
>