From: Adrian Bunk <bunk@stusta.de>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [RFC] [PATCH] Provide users with project support status
Date: Sat, 2 Nov 2019 23:10:30 +0200 [thread overview]
Message-ID: <20191102211030.GA9897@localhost> (raw)
In-Reply-To: <CANNYZj9aCEVwuPqvk=Uz4Jabjwtueo6fd=ksY24PmmK8FvT8aw@mail.gmail.com>
On Sat, Nov 02, 2019 at 04:54:37PM +0100, Alexander Kanavin wrote:
> On Sat, 2 Nov 2019 at 16:30, Adrian Bunk <bunk@stusta.de> wrote:
>
> > The easiest way to get long-term security support in such a situation
> > is often to take the required parts from the BSP layer, and use them
> > to build the product on top of Ubuntu LTS (or Debian).
>
> There is an alternative: engineer the product in such a way that it can be
> updated from one Yocto release to a newer Yocto release.
> This is what I will be pushing for where I work (Daimler).
This is surely desirable but it can only reduce the pain when upgrading,
not make upgrading painless.
Don't let anyone use the gpsd client libraries directly or use the gpsd
functionality to send data over the network - these often bring breaking
changes in new Yocto versions.
"async" becoming a keyword in Python 3.7 broke plenty existing code and
similar breakages might happen in the future, so Python cannot be made
available in such a product.
Do not use glibc in your product, it can happen that some obscure
cornercase was made more standards-compliant - and one of your
users was relying on exactly the old behaviour.
These are just some of the real-life examples I have seen in the
past 12 months, and these are only cases of intentional upstream
changes - there is also some amount of regressions that are just bugs.
> > The core question should really be how to increase the time of upstream
> > support that is usually left when a Yocto-based distibution reaches the
> > user, not just how to tell users that they are screwed.
>
> I'd say information about YP support windows should be more widely known,
> both because it is useful in itself, and because maybe the users will talk
> with their company management and with the project, and figure out
> ways to improve the situation.
What is actually the minimum investment for that?
Six digit sums are small change for companies like Daimler,
but that's a huge amount of money for all the small companies
with a two digit number of employees making embedded products
that just happen to use Yocto.
Yocto lacks a setup where small companies could contribute with
four digit amounts to shared efforts like 5 years of LTS support.
Otherwise the only improvement available is often "don't use Yocto".
> Alex
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
prev parent reply other threads:[~2019-11-02 21:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-01 18:46 [RFC] [PATCH] Provide users with project support status Ruslan Bilovol
2019-11-01 19:02 ` ✗ patchtest: failure for " Patchwork
2019-11-01 20:12 ` [RFC] [PATCH] " Adrian Bunk
2019-11-02 11:01 ` Alexander Kanavin
2019-11-02 13:19 ` Andrey Zhizhikin
2019-11-02 15:30 ` Adrian Bunk
2019-11-02 15:54 ` Alexander Kanavin
2019-11-02 21:10 ` Adrian Bunk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191102211030.GA9897@localhost \
--to=bunk@stusta.de \
--cc=alex.kanavin@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox