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

[Hal Rosenstock]

On Sat, 2006-12-09 at 14:36, Eitan Zahavi wrote:
> Sasha Khapyorsky wrote:
> > On 13:20 Sat 09 Dec     , Hal Rosenstock wrote:
> >   
> >> On Sat, 2006-12-09 at 13:01, Sasha Khapyorsky wrote:
> >>     
> >>> Hi Eitan,
> >>>
> >>> On 16:26 Sat 09 Dec     , Eitan Zahavi wrote:
> >>>       
> >>>> Without another devel branch I will not be able to test patches before 
> >>>> the make it into the trunk.
> >>>>
> >>>> I do not know how to make an automatic mail extraction into patches into 
> >>>> tree such that I can have automatic patch check.
> >>>>         
> >>> You can just pipe emails with patches to git-am (manually after review
> >>> or automatically via procmail), so this will be committed in the local
> >>> tree/branch as you want.
> >>>
> >>>       
> >>>> I am not a great fan of a new branch too.
> >>>>
> >>>> So we need to agree that regression runs resulting with bug reporting 
> >>>> post commit to the trunk is our mode of work.
> >>>>         
> >>> It is ok for me. At least as start point, if we will have automatic
> >>> nightly regression tests for the trunk it is just fine. If this will
> >>> work, and after collecting some experience we may think about
> >>> "quarantine" branch/tree and the regression testing expansion.
> >>>
> >>>       
> >>>> I do not have a big issue with this (but it is more work for Hal).
> >>>>         
> >>> Hal, what do you say?
> >>>       
> >> What is the nightly regression and who will run it ?
> >>     
> >
> > Good question. I guess Eitan has automated regression test suite which
> > is able to pull _committed_ tree and run test series. Eitan, right?
> >   
> Yes that is what we have.
> Both simulated fabrics as well as the ULPs regression which uses OpenSM 
> from the trunk (running a set of tests on smaller fabrics).
> >   
> >> It seems to me that the patches could be automated or a manual procedure
> >> can be put in place so I am not keen on maintaining a pre-trunk branch
> >> but would if I am convinced it can't be done easily by the methods I
> >> mentioned, that the regression would be run nightly on a continuing
> >> basis, and that reports would be issued based on the runs (to interested
> >> parties).
> >>     
> >
> > Ok.
> >
> > I think we could start testing with trunk if we still have the issue
> > with pre-trunk patches. Systematic regression report would be good
> > thing. All this should be good start, and if I understand correctly this
> > can be launched immediately. Then we can deal with pre-trunk stuff.
> >
> > Eitan, how is it hard for you to prepare procmail's rule which will
> > automatically apply the patches from emails to the local pre-trunk
> > tree? Or do you think it is insufficient?
> >   
> I am not sure I can do the procmail thing myself. I am not familiar with 
> it and lack the time to learn.
> I can ask around. But I question why we need to define a different 
> testing method from the rest of the OFA tree?

The request for an extra branch for this is different from the rest of
the OFA tree.

-- Hal

> > Sasha
> >
> >   
> >> -- Hal
> >>
> >>     
> >>> Sasha
> >>>
> >>>       
> >>>> Eitan
> >>>>
> >>>> Sasha Khapyorsky wrote:
> >>>>         
> >>>>> On 18:42 Fri 08 Dec     , Eitan Zahavi wrote:
> >>>>>  
> >>>>>           
> >>>>>> 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
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>>>  
> >>>>>           
> >
> > _______________________________________________
> > 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
> >   
>