All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Yang <liezhi.yang@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	Martin Jansa <martin.jansa@gmail.com>
Cc: oe-core <openembedded-core@lists.openembedded.org>
Subject: Re: PRServer's problem
Date: Fri, 20 May 2016 10:27:50 +0800	[thread overview]
Message-ID: <573E7626.8040605@windriver.com> (raw)
In-Reply-To: <1463653077.4578.115.camel@linuxfoundation.org>



On 05/19/2016 06:17 PM, Richard Purdie wrote:
> On Thu, 2016-05-19 at 18:12 +0800, Robert Yang wrote:
>> On 05/19/2016 05:45 PM, Richard Purdie wrote:
>>> To be really clear, OE-Core will not have a different signature
>>> policy
>>> on release branches since that differing policy would break user
>>> expectations and also wouldn't get tested apart from on the branch
>>> so
>>> we'd have less confidence it was working.
>>
>> Yes, I agree with this, I just used stable release as an example (big
>> changes won't happen on a stable release).
>>
>>>
>>> Users are free to set their own policies, the system was designed
>>> to do
>>> that. If WindRiver wants to have a much more permissive policy, I'm
>>> more than happy for them to do so.
>>
>> Thanks, frankly speaking, not only WindRiver wants this. After cloud
>> computing and virtualization gets hot, more and more users want to
>> customize their own images (for saving disk space, memory and
>> security
>> reason), oe/yocto is very good at customizing images, so more and
>> more people try to use it to build their own distros, where live
>> upgrades becomes very important.
>
> I understand that. So are we going to get binary diff working? Its the

Thanks everyone, it seems that this is the best way we have, I will
try packagefeed-stability class.

// Robert

> only viable solution we have to the problem at the moment that I know
> of. Randomly hacking bits of the signature generation isn't going to
> help this unfortunately.
>
> Cheers,
>
> Richard
>
>


  reply	other threads:[~2016-05-20  2:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-18  6:09 PRServer's problem Robert Yang
2016-05-18  7:34 ` Joshua G Lock
2016-05-18  8:13   ` Robert Yang
2016-05-18  7:39 ` Martin Jansa
2016-05-18  8:03   ` Robert Yang
2016-05-18  9:20     ` Martin Jansa
2016-05-18  9:31       ` Robert Yang
2016-05-18 10:15         ` Martin Jansa
2016-05-19  2:33           ` Robert Yang
2016-05-19  3:10             ` Robert Yang
2016-05-19  9:45               ` Richard Purdie
2016-05-19 10:12                 ` Robert Yang
2016-05-19 10:17                   ` Richard Purdie
2016-05-20  2:27                     ` Robert Yang [this message]
2016-05-19 10:37                   ` Joshua G Lock
2016-05-19 11:10                     ` Paul Eggleton
2016-05-19  8:47             ` Martin Jansa
2016-05-19  9:40               ` Richard Purdie
2016-05-19  9:45               ` Robert Yang
2016-05-19 10:24                 ` Martin Jansa
2016-05-18 12:27         ` Sergey 'Jin' Bostandzhyan
2016-07-27  8:06           ` Robert Yang
2016-07-27  8:30             ` Sergey 'Jin' Bostandzhyan
2016-07-27  8:43               ` Robert Yang
2016-05-20 10:00 ` Mike Looijmans

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=573E7626.8040605@windriver.com \
    --to=liezhi.yang@windriver.com \
    --cc=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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.