All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Garman <scott.a.garman@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Yocto Project Discussion <yocto@yoctoproject.org>,
	"poky@yoctoproject.org" <poky@yoctoproject.org>
Subject: Re: Recipe Updating Status and call to action
Date: Thu, 16 Dec 2010 13:56:31 -0800	[thread overview]
Message-ID: <4D0A8B0F.8000208@intel.com> (raw)
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1504D5F4093D7@shsmsx502.ccr.corp.intel.com>

On 12/15/2010 06:40 PM, Tian, Kevin wrote:
> On the other hand, along with this I realize that there's one area we need further
> discuss. How often should we upgrade packages in a given release cycle? MeeGo
> only does once. For Yocto we want to keep our recipes in cutting-edge which is
> why we schedule two upgrade windows in M2 and M3 this time.

I'd like to question this. Is the goal for Poky/Yocto to track the 
bleeding-edge releases of software, or is the goal to be a well-tested 
and stable foundation for embedded software applications?

Upgrading a recipe within a couple of weeks of its release may end up 
using more of our resources if/when we encounter new bugs that were 
introduced in the new release. Or worse, if we don't encounter them 
during distro builds and then our users take our release and discover 
them for themselves.

I'm not saying we need to be as conservative as long-term-support 
enterprise Linux distros, but IMHO I think racing to always upgrade our 
recipes to versions released a handful of weeks ago can be 
counterproductive in many situations.

A policy I might put forward for consideration is this: recipe upgrades 
are done once per release cycle, and upstream versions that have come 
out within the last 30 days should not be upgraded unless we have a 
really good reason for doing so.

Scott

-- 
Scott Garman
Embedded Linux Distro Engineer - Yocto Project


WARNING: multiple messages have this Message-ID (diff)
From: Scott Garman <scott.a.garman@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Yocto Project Discussion <yocto@yoctoproject.org>,
	"poky@yoctoproject.org" <poky@yoctoproject.org>
Subject: Re: [poky] Recipe Updating Status and call to action
Date: Thu, 16 Dec 2010 13:56:31 -0800	[thread overview]
Message-ID: <4D0A8B0F.8000208@intel.com> (raw)
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1504D5F4093D7@shsmsx502.ccr.corp.intel.com>

On 12/15/2010 06:40 PM, Tian, Kevin wrote:
> On the other hand, along with this I realize that there's one area we need further
> discuss. How often should we upgrade packages in a given release cycle? MeeGo
> only does once. For Yocto we want to keep our recipes in cutting-edge which is
> why we schedule two upgrade windows in M2 and M3 this time.

I'd like to question this. Is the goal for Poky/Yocto to track the 
bleeding-edge releases of software, or is the goal to be a well-tested 
and stable foundation for embedded software applications?

Upgrading a recipe within a couple of weeks of its release may end up 
using more of our resources if/when we encounter new bugs that were 
introduced in the new release. Or worse, if we don't encounter them 
during distro builds and then our users take our release and discover 
them for themselves.

I'm not saying we need to be as conservative as long-term-support 
enterprise Linux distros, but IMHO I think racing to always upgrade our 
recipes to versions released a handful of weeks ago can be 
counterproductive in many situations.

A policy I might put forward for consideration is this: recipe upgrades 
are done once per release cycle, and upstream versions that have come 
out within the last 30 days should not be upgraded unless we have a 
really good reason for doing so.

Scott

-- 
Scott Garman
Embedded Linux Distro Engineer - Yocto Project


  reply	other threads:[~2010-12-16 21:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-16  0:58 Recipe Updating Status and call to action Saul Wold
2010-12-16  2:40 ` Tian, Kevin
2010-12-16  2:40   ` [poky] " Tian, Kevin
2010-12-16 21:56   ` Scott Garman [this message]
2010-12-16 21:56     ` Scott Garman
2010-12-17  2:02     ` Tian, Kevin
2010-12-17  2:02       ` [poky] " Tian, Kevin
2010-12-16 14:17 ` Yu, Ke
2010-12-16 23:19   ` Saul Wold
2010-12-17  7:07     ` Yu, Ke

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=4D0A8B0F.8000208@intel.com \
    --to=scott.a.garman@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=poky@yoctoproject.org \
    --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.