From: Mark Hatle <mark.hatle@windriver.com>
To: <yocto@yoctoproject.org>
Subject: Re: Does Yocto need some "LTS" releases?
Date: Thu, 8 May 2014 15:11:56 -0500 [thread overview]
Message-ID: <536BE50C.3000006@windriver.com> (raw)
In-Reply-To: <6710F7A1-6564-49CC-AE7C-1544633E5D84@keylevel.com>
On 5/8/14, 2:54 PM, Chris Tapp wrote:
> I've had a few potential clients ask how security updates and general patches
> are applied to embedded products built using Yocto.
The Yocto Project, via it's contributors usually provides support for the -two-
releases + master.
That means effectively a one year community (best-effort) support model for each
release. So today that would be 1.5 and 1.6. (Master is continuously
developed, and I'd expect any relevant fixes to go there as well.)
Note, this is all contingent upon contributions from Yocto Project members and
the Open Embedded community at large. Without contributions, there is no support.
> If they're really embedded, then the only way to to this is by replacing the
> rootfs - especially when they boot read-only.
See the million threads on "field upgrade". There is no one answer. Device
upgrade, Image upgrade, package upgrade, and file upgrades are all
possibilities... but these need to be built into the device during it's design.
There are no best practices available, as everyone seems to have different
requirements.
> A second complication is when support for a BSP gets dropped so later
> versions, which generally include updates and patches, can't be used.
If you are releasing a product, you shouldn't be expecting to migrate (in a
product lifecycle) from YP 1.4 to YP 1.5 to YP 1.6, etc. Each release is
individual, and an overall target based upgrade and BSP obsolescence is not part
of the project. This is really the realm of the device manufacturer, OSV and
other commercial vendors of YP components.
> It feels to me as if there should be some "LTS" releases which developers
> could focus on when choosing a version.
It all comes down to contributions in the end. If nobody is contributing, don't
expect updates. There has been talk over time of an LTS type release. I've
heard everything from extending the 1 year to '2' years.. or as contributions
are available.
But if you want long term support, your best bet is to find an OSV (or other
Yocto Project participant) that is willing to do long term support and
maintenance of a product.
(Speaking for Wind River for a second, we do offer extended support for many
many more years then what I would ever expect the community to support. I would
expect the same from our competitors.)
> Or is there already some way of doing this that I just haven't spotted?
This is where community support really transitions to commercial. The community
is interested in enabling new designs and 'maker' projects. Commercial is
interested in building products and long term support. (IMHO, others might
disagree.)
--Mark
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
next prev parent reply other threads:[~2014-05-08 20:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 19:54 Does Yocto need some "LTS" releases? Chris Tapp
2014-05-08 20:11 ` Mark Hatle [this message]
2014-05-08 21:00 ` Chris Tapp
2014-05-08 21:53 ` Michael Stickel
2014-05-08 22:30 ` Philip Balister
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=536BE50C.3000006@windriver.com \
--to=mark.hatle@windriver.com \
--cc=yocto@yoctoproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.