On 04/19/2018 09:17 AM, Richard Purdie wrote: > [Widely cross posted but please reply to openembedded-core only for > want of picking somewhere to discuss this] > > The next big question facing us is what would we like to do in 2.6? > What can we do with the resources we have? > > I'm proposing to hijack the next monthly Yocto Project technical > call[1] and dedicate it to 2.6 planning. I'm going to detail some high > level 'big' ideas blow in this email from a feature development > perspective. Anyone is welcome to join the call (or reply) and I'm > happy to answer questions about the ideas below and hear suggestions of > others. > > [1] https://www.yoctoproject.org/monthly-technical-call/ > > Ultimately, ideas will be turned into bugzilla enhancement entries. It > will then be a case of seeing who is willing to step up and help work > on any given feature. We're using the "2.99" target milestone as our > holding area for potential ideas, only moving to 2.6 when we have a > solid commitment for someone to do something. > > If nobody steps up for something, chances are it will just get pushed > out as a "Future" idea. In the past, Intel in particular has stepped up > and done a lot of feature work but for various reasons, this is not > likely to happen going forward as they focus more in Intel specific > work. > > At the end of the day, we'll process the changes that make it onto the > mailing list by the freeze deadlines for the milestones. If its not > there, it won't be in the release and 2.6 will be what people put into > it. > > List of high level 'big' ideas: > > - Reference binary package feed (in particular to test upgrade paths) > - > Secure/trusted boot support in OE-Core > - Improved security tools (e.g. > CVE database scanning) I have ideas on the CVE scanning stuff. > - Provide sstate feed out the box for reference > - > Improve binary output testing (esp. reproducibility, upgrade paths) > - > Widen the scope of our automated testing infrastructure (include > more > layers) > - Roll processes and tooling into the wider ecosystem (e.g. > meta- > openembedded) > - Ability to make builds more efficient by output > comparison and > sstate prebuilt reuse in many more cases. Maybe sstate > equivalence > server > - Completion of migration to new autobuilder > codebase and > infrastructure Count me in on the new autobuilder codebase
> - Out of box experience/layer setup > tooling > - Improved binary reproducibility > > Features aren't all we need to plan for. There are other areas that > need work/help: > > Many other smaller features > > There are too many for me to list/call out individually but search > bugzilla for 2.99 Medium+ items. A good example is adding > support for inter-multiconfig dependencies which is a small > remaining multiconfig item which would make a big difference to > certain workflows. > > Another harder example is parallelisation of oe-selftest. Its > currently the thing which ends up taking the longest in most of our > builds, improving its performance would reduce overall testing times. > > OE-Core Recipe maintenance: 840 recipes in OE-Core > > - General recipe > updates > - Security fixes > - Recipe specific bugs/regressions > - Adapt > to new technologies/upstream changes > > General patch review > > ~5000 commits/year which need review, testing, identifying > regressions, merging > > General regressions > > Regressions tests we have are good but don't catch every race > condition or intermittent problem. We end up having to track > down several, particularly runtime testing instability > > Bug fixing user issues > > Users find new use cases and workflows and identify bugs which then > need to be addressed > > For example we can't default to mem-res bitbake as there are known > > issues. > > Maintain the tools > > We directly maintain tools like bitbake, pseudo, devtool, recipetool > opkg, yocto-autobuilder, patchwork+patchtest, wic > > Stable release maintenance > > People all want stable releases and security fixes but someone has > to make these happen. I am fine continuing maintaining the stable branchs. - Armin > > > Help in any and all of these areas is much appreciated. Also keep in > mind the things above are just to get people thinking. If there are > changes you'd like to see, now is your chance to proposal and work on > them to make them a reality. > > Cheers, > > Richard > > > > _______________________________________________ > Openembedded-architecture mailing list > openembedded-architect...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto