>From: Garman, Scott A
>Sent: Friday, December 17, 2010 5:57 AM
>
>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?
I think the both. :-)
>
>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.
This is always being a tradeoff in all distributions. There's no simple
guideline
whether there's severe risk to upgrade to a latest release, and I think the
one general rule is to pick up a newer release with enough stability. How to
judge that? This finally goes to the owner of each recipe.
>
>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.
>
I think there's no simple guideline meaningful in general context like this.
All the
decisions should come to the actual recipe maintainer, based on his knowledge
in this specific area. Once we involve with upstream more closely, we should be
able to tell whether a new release is worthy to go or not in most cases.
Besides that, what in general we can do is about the process.
That's why we come up a two phase upgrade windows in 1.0. With the first window
as the major upgrade, and the 2nd window to catch up minor version changes which
should be with little risk. If there's important release coming out in 2nd
window, we
(again mainly the recipe owner) again need to make decision instead of a simple
global rule "to go" or "not to go". As I raised in early thread, I suggest to
those
minor version upgrade in later of 2nd window.
That's also why we're currently developing the package reporting system, which
is
expected to check upstream release periodically and once a new release coming
out the maintainer gets notified to make decision.
So in a nutshell:
- the general goal is to being cutting-edge
- we work out a process which give recipe maintainers enough
opportunities
to check new releases of packages they own, toward our 'cutting-edge' goal
- Saul generates a general candidate list from those info in start of
each
upgrade window
- then it's always recipe maintainers to make decision whether a new
release
should go or not, based on its stability, new features and risks given time to
Yocto
release point. If there's a decision not to upgrade, the maintainer should
document
it well
Having said that so far our process is not exactly as expected yet, and our
expertise
on each area still need time. But I think that's the what we'll need to be. :-)
Thanks
Kevin
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
