[Automated-testing] [Openembedded-architecture] Yocto Project LTS Proposal/Discussion

[Petr Nechaev]

Hello,

 I am sorry if this is off-topic, I can only speak as a user of yocto.
But what is the goal of doing half-year releases along with LTS ones
if we have limited and possibly declining amount of resources ?
 How many users do really need half-year releases and fast package
updates --vs-- how many do need LTS and stable ABI? (any data on
this?)
     What is the shortest time-to-release for a yocto-based project,
do they expect 'all' packages to be 'latest' or just a few to be
'recent' that they can upgrade themselves?

 Instead of introducing LTS as a *new* policy, could we just change
the release model:
1. Release once a year (or even every two years).  Less testing - less hassle
2. Support every release for 5 years:
   - 3 years of full support and updates
        New kernel (recipe) versions are introduced as new optional
(DEFAULT_PREFERENCE = "-1") recipe files. We test both.  If one wants
- they can upgrade..
        Basic ABI like libc or python are never changed.
        Individual ABIs (say, gui framework upgrades) are up to the
system designer
   - 2 years of critical bugfix, community only

I imagine the overall amount of testing efforts to be less than we have now.

---
Petr

---
Petr


On Mon, Oct 28, 2019 at 1:56 PM Rich Persaud <persaur at gmail.com> wrote:
>
> On Oct 28, 2019, at 6:23 AM, Adrian Bunk <bunk at stusta.de> wrote:
> >
> > Hi Rich,
> >
> > most of what you are writing is unfortunately quite far from the actual
> > problems regarding Yocto LTS.
> >
> > Yocto LTS might not happen at all due to a lack of resource commitments.
> >
> > Discussing what additional work could be done for Yocto LTS is
> > therefore not productive, unless you are the one doing this work.
> >
> > If you manage to convince your employer or a customer to make
> > a resource commitment for Yocto LTS, everyone would be extremely
> > grateful since this would help solving the biggest problem.
>
> As stated at the beginning of the thread, few companies can alone resource the work needed for LTS support, given the complexity of the software supply chain.  As stated in the previous email, Linux Foundation, Google, Microsoft and RedHat today announced their pooled investment of resources into a test project (Kernel CI) with historical resource challenges.
>
> If long-term support for OpenEmbedded is not receiving sufficient resource investment, one question is:  which similar projects *are* receiving investment?  Two examples were provided, one based on OE/Yocto.  Has Yocto asked Microsoft to contribute resources to Yocto LTS?  Another question that can be posed to potential contributors:  what changes to Yocto LTS scope (phase 1 or 2) would enable contribution of pooled resources?
>
> OpenXT uses OpenEmbedded to develop systems with hardware-assisted security properties.  If Yocto LTS can reduce our existing test burden on real hardware, there is potential for collaboration.  Currently-scoped Yocto LTS would not be a good fit for testing security properties, especially if the virtual test hardware is based on Ubuntu instead of OpenEmbedded meta-virtualization + bitbake guarantees for software supply chain integrity.
>
> Rich
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture