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 <[email protected]> wrote:
>
> On Oct 28, 2019, at 6:23 AM, Adrian Bunk <[email protected]> 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
> [email protected]
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
_______________________________________________
Openembedded-architecture mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
