On Wed, 2019-11-06 at 13:46 -0800, akuster808 wrote: > On 11/6/19 7:37 AM, Mikko Rapeli wrote: > QA resources have been a donation from Intel and Windriver above > their membership fees. I don't fee right asking them to run QA.
> > patches aiming at yocto 2.5 sumo. If not, would be really nice if > > someone could collect patches into sumo-next or sumo-contrib branch > > where us > > users could be in charge of all Quality Assurance. > > I have collected other patches for sumo and built them locally but I > have no way to inform Richard they pass an AB builds or automated > testing for them to get into mainline sumo. Given the discussions around LTS and the fact we'd need to do *something* with the autobuilder to help support it, I've been experimenting. I created a sumo-next branch with a uninative update and Mikko's patches and then managed to get it to build (and pass) on the autobuilder. I did directly merge a bitbake fix to the 1.38 branch to avoid test failures too. The autobuilder successfully builds a-full for sumo-next. Compared to a normal build the differences are: * unsupported workers are removed from the pool for sumo so it only builds on a subset of the infrastructure * no buildperf tests * there are no supported fedora workers left so no oe-selftest-fedora * no ptest image execution (we never did this with sumo) * no test result output (wasn't present in sumo and never backported) I'm prepared to merge sumo-next on the basis of these results and use it as a model for how we could continue to get critical patches into older releases. More work would be needed to see if any older releases could work. At this point the TSC needs to discuss LTS and what our branch policy may be going forward but this does add useful data to that discussion and may help influence those discussions. [For reference I did have to seek advice from upstream buildbot on how to avoid a bug and its taken quite some experimenting to find the magic to make this work. I did have to update the autobuilder-helper sumo branch to be in sync too]. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
