From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Robert Yang <liezhi.yang@windriver.com>,
Martin Jansa <martin.jansa@gmail.com>
Cc: oe-core <openembedded-core@lists.openembedded.org>
Subject: Re: PRServer's problem
Date: Thu, 19 May 2016 10:45:56 +0100 [thread overview]
Message-ID: <1463651156.4578.113.camel@linuxfoundation.org> (raw)
In-Reply-To: <573D2EAF.9010602@windriver.com>
The bottom line is that the system is setup to be sensitive to changes.
Where we've had cases where we haven't reacted to changes, people have
complained and we've ended up making sure we do react to them. The
patch you reference was one such case where users complained we didn't
react enough.
You can't have things both ways, where it reacts to all changes but
also never reacts to changes which don't have any visible effect on the
end result (how do you know?).
The binary diff tool is likely going to be the only way to ultimately
control a binary package feed and is still the only way I can see of
solving this problem. I'd love some help on making that work. Making
deterministic binaries is a large part in making that tool effectively
ultimate and we had some great work on that in the last release.
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.
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.
Cheers,
Richard
next prev parent reply other threads:[~2016-05-19 9:46 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 [this message]
2016-05-19 10:12 ` Robert Yang
2016-05-19 10:17 ` Richard Purdie
2016-05-20 2:27 ` Robert Yang
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=1463651156.4578.113.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=liezhi.yang@windriver.com \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox