On Thu, 2019-11-07 at 07:55 -0800, akuster808 wrote: > > On 11/7/19 7:03 AM, Richard Purdie wrote: > > 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. > Are you taking the other patches also submitted for sumo ?
I am worried about what the bigger picture for this looks like but we could try testing them. I think the TSC needs to discuss this. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
