All of lore.kernel.org
 help / color / mirror / Atom feed
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
>
>



  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.