xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@citrix.com>,
	Ian Jackson <iwj@xenproject.org>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: Re: [XEN PATCH] xen: allow XSM_FLASK_POLICY only if checkpolicy binary is available
Date: Fri, 16 Jul 2021 16:34:52 +0200	[thread overview]
Message-ID: <7e49c906-2598-7243-e786-be8b88ea50db@suse.com> (raw)
In-Reply-To: <17a250d3-1c1b-f079-c950-5590975e56ae@citrix.com>

On 16.07.2021 15:15, Andrew Cooper wrote:
> On 15/07/2021 07:25, Jan Beulich wrote:
>> On 14.07.2021 18:17, Anthony PERARD wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -25,6 +25,9 @@ config GRANT_TABLE
>>>  config HAS_ALTERNATIVE
>>>  	bool
>>>  
>>> +config HAS_CHECKPOLICY
>>> +	def_bool $(success,$(CHECKPOLICY) -h 2>&1 | grep -q xen)
>>> +
>> This is no different from other aspects of "Kconfig vs tool chain
>> capabilities" sent out last August to start a discussion about
>> whether we really want such. Besides Jürgen no-one cared to reply
>> iirc, which to me means no-one really cares one way or the other.
> 
> You know full well that upgrading Kconfig was specifically to be able to
> use this functionality, and you know full well that I firmly support
> using this mechanism, because we've had both of these arguments several
> times before.
> 
> The absence of replies doesn't mean people agree with you, or even that
> they don't care.  It either means people didn't read the email, or
> didn't have time to reply, or didn't feel like wasting time rehashing
> the same arguments yet again with no hope for progress.
> 
> 
> If you really insist on refusing to features specifically intended for
> the improvement of our build processes, then call a vote so we can be
> done with the argument for once and for all.

I'm sorry Andrew, but this is not a way to discuss controversial items.
Back at the time you were pointing me at a discussion at a summit that
I didn't recall and hence presumably didn't attend for whatever reason.
Whatever may have been the result of such a discussion imo _has_ to be
under the precondition that no other contrary arguments arise. I do not
recall there having been spelled out up front this specific purpose of
upgrading kconfig, and even if it was spelled out, the ramifications
may not have become clear until the actual first uses were proposed.
It has to be possible to change views at such a point even for people
who did signal agreement earlier on. Not to speak of unaware ones.

Further iirc it was you who told me to start a mail thread about the
issue. Which I did. And now you say "... didn't feel like wasting time
rehashing the same arguments yet again with no hope for progress"? Can
you please point me to a place where those "same arguments" are put
down in writing, including reasons why they were either turned down or
considered of less relevance?

I can't help the feeling that when our opinions don't match you try to
silence me by whatever means you find suitable - ignoring my input,
claiming my earlier agreement, denying me any influence, etc. I'm
afraid I have to say that I don't think this is a way to run a
community project. The only two ways to get past my objections (or
really just reservations here) are to either convince me (which you
don't appear to be willing to) or to outvote me (which you haven't
tried at all so far if I'm not mistaken).

Jan



  reply	other threads:[~2021-07-16 14:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14 16:17 [XEN PATCH] xen: allow XSM_FLASK_POLICY only if checkpolicy binary is available Anthony PERARD
2021-07-14 16:51 ` Jason Andryuk
2021-07-14 17:09 ` Andrew Cooper
2021-07-15  6:25 ` Jan Beulich
2021-07-16 12:36   ` Anthony PERARD
2021-07-16 13:15   ` Andrew Cooper
2021-07-16 14:34     ` Jan Beulich [this message]
2021-07-16 16:23     ` Anthony PERARD
2021-07-16 12:38 ` [XEN PATCH v2] " Anthony PERARD
2021-07-16 13:00   ` Andrew Cooper
2021-07-19  7:37   ` Jan Beulich
2021-07-19 10:47     ` Anthony PERARD
2021-07-19 11:04       ` Jan Beulich
2021-07-19 14:33         ` George Dunlap
2021-07-16 15:26 ` [XEN PATCH] " George Dunlap
2021-07-16 15:50   ` Juergen Gross
2021-07-16 15:56   ` Anthony PERARD
2021-07-16 16:14   ` Andrew Cooper
2021-07-19  7:10     ` Jan Beulich
2021-07-16 16:27   ` Anthony PERARD

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=7e49c906-2598-7243-e786-be8b88ea50db@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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;
as well as URLs for NNTP newsgroup(s).