[yocto] [Openembedded-architecture] Yocto Project LTS Proposal/Discussion

Nicholas Krause xerofoify at gmail.com
Thu Oct 24 18:22:50 PDT 2019


On 10/24/19 8:15 PM, Rich Persaud wrote:
> This came directly to me -- did you mean to copy the list?
>
> Rich

Sorry misclick on my end Rich.

Nick

>
>> On Oct 24, 2019, at 20:13, Nicholas Krause <xerofoify at gmail.com> wrote:
>>
>> 
>>
>>
>> On 10/24/19 8:08 PM, Rich Persaud wrote:
>>> /(adding the automated-testing list)/
>>>
>>> On Oct 24, 2019, at 18:52, Richard Purdie 
>>> <richard.purdie at linuxfoundation.org> wrote:
>>>>
>>>> I'm posting this to openembedded-architecture since it probably is the
>>>> best place for discussions about OE/Yocto planning.
>>>>
>>>> The Yocto Project TSC believes one of the things needed for YP and for
>>>> OE is more information being pulled together about how an LTS release
>>>> could work. The document linked to below is the information it was able
>>>> to collate together on the subject. Its the result of some long
>>>> discussions by the TSC.
>>>> ...
>>>> The key thing needed to make this happen is a resource commitment to
>>>> it. Without such a commitment it is simply not feasible.
>>>
>>> Vendors who provide commercial support for OE/Yocto-based products 
>>> may already be investing downstream resources for equivalent "LTS" 
>>> support.  May be useful for the document to show the financial 
>>> benefits of shifting a percentage of downstream LTS validation 
>>> resources to upstream Yocto LTS.
>>>
>>>> There may be
>>>> new companies willing to join the project in order to make it happen,
>>>> if so we should talk further.
>>>>
>>>> The document:
>>>>
>>>> https://docs.google.com/document/d/1AwAFDf52f_FoXksbHEVUMlu4hpcI0JMGVG-Kj_sUkyc/
>>>
>>> > The project components to be covered would need to match those 
>>> included in our standard release process and should be clearly 
>>> defined. Those components would be:
>>> > Bitbake
>>> > OE-Core
>>> > Meta-yocto
>>> > yocto-docs
>>> ...
>>> > For simplicity, it is also proposed that only automated testing be 
>>> used for testing the LTS and that any current manual QA is not 
>>> performed.
>>> ...
>>> > Only run virtualized tests
>>> > Only support one host distro, an Ubuntu LTS as it has right lifespan
>>>
>>> When the first Yocto LTS release is available, could that become the 
>>> host distro for automated testing?  That would provide Yocto 
>>> automated testing with supply chain integrity benefits from Yocto. 
>>>  If we take that path, with automated testing based on 
>>> virtualization, could we add meta-virtualization to the list of 
>>> Yocto LTS release components?
>>>
>>> Yocto-on-Yocto automated testing could reduce risks [1] that impact 
>>> software supply chains. A potential topic for the ATS event [2] next 
>>> week.
>>>
>>> Rich
>>
>> One concern on the toolchain or lanuage side  is what happens if 
>> something like a new C++ release happens or similar. Do you plan on 
>> allowing toolchain migration to using the newer version of a given 
>> lanuage.
>>
>> May be worth considering,
>>
>> Nick
>>
>>>
>>> [1] https://www.platformsecuritysummit.com/2019/speaker/sherman/
>>>
>>> [2] https://elinux.org/Automated_Testing_Summit_2019
>>>
>>>
>>> _______________________________________________
>>> Openembedded-architecture mailing list
>>> Openembedded-architecture at lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20191024/47bbda3d/attachment-0001.html>


More information about the yocto mailing list