OpenBMC 11/20 community telecon - Minutes

[Brad Bishop]

As always, If there are any errors or omissions please just reply with
a correction.

Thx - brad

OpenBMC Community Teleconference 11/20 Minutes
--------------------------------

Brad B
Andrew J
Joel S
James M
Jeremy K
George K
kurt T
Andrew G
Sai D
Milton M
Nancy Y
Brendan H
Ed T

—————
George - test suite, robot framework.  you can take a look
pick up openbmc upstream images built and do CI test, ci test does code update, power on, check user interfaces.
test repository to report automation issues
open bugs if issues are found

Ed - do you do any end 2 end testing comparing results of different test cases
  didn’t see any end to ends tests
brad - whats an end to end test
Ed - push power, test leds, check
Ed - george, can you send a link to a test that powers on with ipmi and checks rest?

Andrew G - gave overview of repo CI.
	• recipe bumps, bitbake build - runs hw CI (subset)

Ed - do you do ac cycle testing?
Andrew G, yes.  george - yes, have robot tests but not fully automated.
Andrew G - issue 2635 - general cleanup
	• Ed, phosphor-logging turned off
	• Nancy - phosphor-logging is used
	• arch could be revisited
	• utility improvements - Nancy - we use it during bringup

Andrew G - issue 2635 - devops flow
	• looking for ways to improve
	• Ed - how does the permissions work for server?  Andrew - Jenkins slave, ssh key
	• Ed - might be able to get some time on a Kubernetes cluster.
	• Andrew - Qemu - get qemu going again
	• Andrew - hardware failures - data in the gerrit link - place to put failure data. 

Andrew - how do we test on other hardware?
	• run it internally behind firewall, push failure data out to github
	• or on the network
	• Kurt - open stack does it the first way, talked details

Brad - lets do on the list
Andrew - whats the priority
Nancy - test design posted on IRC
Brendan - why docker?  why not OE sdk?
joel - other tools don’t use sdk
Brendan - would be useful to build and test locally

—————
Ed - code review velocity
	• patch merged in 14hrs.  question of whats the norm. 
	• brad went over the process

Ed - wants a more stable master branch.  delayed approach to merging patches
	• either through testing or review, how to keep the master branch more stable

Nancy - have you experienced instability?
Ed - User daemon was swapped out
Joel - hard to keep out of tree code stable
Nancy - have similar concerns.
Andrew - how does code sitting in review help?
Ed - testing probably trumps everything?

Brad - how does this work for the kernel?
Jeremy - external ABI - never breaks
	• internal API - in tree/out of tree
Joel - little bit different - we have runtime interfaces
Milton - OpenStack does pregate testing, on Linux, two opportunities to complain - linux-next, 6-8 weeks of stabilzation
Brad - merge window?
Milton - need more tests though
Nancy - merge window good idea, but personally won’t have test infrastructure up for a bit.
Brendan - automated upstream tests sort of invalidates the need for a merge window.  could be useful until we get more upstream testing?
Jeremy - can CI infrastructure we handle the bursty nature of a merge window?
Andrew - probably.  it might just take awhile to get through.
Brad - send a note to the list about a merge window.

Ed - secure coding guidelines
what are everyones experience with these?  (memcpy vs memcpy_s) ?
brad - what about busybox - ed - exception process, run static analysis tools