[OE-core] [Openembedded-architecture] 2.6 planning proposals and meeting

[akuster808]

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-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture