Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Philip Balister <philip@balister.org>
To: Khem Raj <raj.khem@gmail.com>, "Burton, Ross" <ross.burton@intel.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/4 V2] systemd: Upgrade 219 -> 224
Date: Thu, 20 Aug 2015 09:04:54 -0400	[thread overview]
Message-ID: <55D5D076.5000106@balister.org> (raw)
In-Reply-To: <CAMKF1soxndfF7OLyAx-c49WBDdLhbbecQhxSj7ixeo2hFsRcTA@mail.gmail.com>

On 08/19/2015 10:21 PM, Khem Raj wrote:
> On Wed, Aug 19, 2015 at 12:55 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> On 17 August 2015 at 16:41, Khem Raj <raj.khem@gmail.com> wrote:
>>>
>>> There are many reasons, for me its overlay support for systemd-nspawn,
>>> networkd has got many new features that is now usable w.r.t. IP forwarding,
>>> vxlan etc.
>>> and it has many bug fixed in those 2000 odd commits since 219, no
>>> different then any other package upgrades we do in general it keep the
>>> upgrade workload lower as we roll the releases.
>>> Any specific concerns ?
>>
>>
>> Can we get an updated patch with a clearer commit log?

I've also heard that as systemd evolves, more binaries are getting added
to the base package that should be packaged separately for people
interested in small images. I do not have personal experience here, but
wanted to pass along the feedback.

We should look at buildhistory packaging differences when we do upgrades.

Philip

> 
> sent a v2 with more descriptions
>>
>> My concerns with the systemd upgrade were simply that until now we were
>> tracking the systemd-stable repository.
> 
> it was only in last release that it was switched to use stable
> repository in hope that it will help
> backporting to 1.8 release any future updates done on 219 easily. We
> never were pinned to stable release
> it just was a coincidence that 219 was right in time for 1.8 release.
> We want to avoid situations where core recipes
> from oe-core are overridden in other layers and staying latest helps that.
> 
>   If we want to change that policy to
>> the latest release, that's fine by me.
>>
>> Anyone else have an opinion here?
>>
>> Ross


  reply	other threads:[~2015-08-20 13:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-17  5:03 [PATCH 2/4 V2] systemd: Upgrade 219 -> 224 Khem Raj
2015-08-17 12:42 ` Burton, Ross
2015-08-17 15:41   ` Khem Raj
2015-08-19 19:55     ` Burton, Ross
2015-08-20  2:21       ` Khem Raj
2015-08-20 13:04         ` Philip Balister [this message]
2015-08-21  1:17           ` Khem Raj
2015-08-21  1:46             ` Randy MacLeod
2015-08-21  1:55               ` Khem Raj
2015-08-21 10:14               ` ChenQi
2015-08-21 15:34                 ` Khem Raj
2015-08-23  2:26                 ` Khem Raj

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=55D5D076.5000106@balister.org \
    --to=philip@balister.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    --cc=ross.burton@intel.com \
    /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