Re: [Xen-devel] [PATCH] Intel TXT: add reviewer, move to Odd Fixes state

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

On 30 Jul 2019, at 11:08, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:

On 7/30/19 10:54 AM, Julien Grall wrote:

Hi Jan,

On 30/07/2019 10:05, Jan Beulich wrote:

On 30.07.2019 10:54, Julien Grall wrote:

On 7/30/19 9:29 AM, Jan Beulich wrote:

On 30.07.2019 08:56, Lukasz Hawrylko wrote:

Support for Intel TXT has orphaned status right now because
no active maintainter is listed. Adding myself as reviewer
and moving it to Odd Fixes state.

Signed-off-by: Lukasz Hawrylko <lukasz.hawrylko@xxxxxxxxx>
---
    MAINTAINERS | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 89a01b710b..ca300e87c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -240,7 +240,8 @@ S:    Maintained
  F:    tools/golang
  INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
-S:    Orphaned
+R:    Lukasz Hawrylko <lukasz.hawrylko@xxxxxxxxx>
+S:    Odd Fixes

I guess we should give it a few days for objections to be raised
against this slightly inconsistent state, but I think that's the
best way to express the current state of things (hence my
suggestion to this effect). If no objections turn up, I've queued
this onto my to-be-committed list.

I have some objections regarding the process itself... On the first
version of this patch, it was pointed out that the e-mail shouldn't
be sent with disclaimer. This is now the third version and the
disclaimer is still present.

Okay, I must have missed both earlier requests to this effect. I've
gone back to the list archives though, and I couldn't find any such
request either from July or June. Therefore ...

The first version was sent from March [1].

Technically, no patch should be applied when there are a disclaimer.

... I'd also like to ask for the background of this. It would never
have occurred to me that I should pay attention to possible
disclaimers or alike on patch submissions.

The disclaimer tell you this patch may contain confidential information
and you are not allowed to distribute it... While I agree this makes no
sense for public ML, we still have to stay on the safe side. How do you
know this was not sent by mistake? Note that this question makes little
sense on MAINTAINERS file...

In general, I am following Greg KH advice here [2] and refrain to answer
any e-mail with disclaimer. I would actually advocate xen-devel to
completely block those e-mails.

I think "refraining from answering" and "blocking from the list" is a
bit too strong: after all, the disclamer does say "may", and it should
be pretty clear that the "intended recipients" includes anyone on xen-devel.

But for code itself, which will end up being used in the products of
large corporations with deep pockets, I agree should be absolutely clear
of legal doubt; as such, having such a disclaimer on the patches should
be disallowed.  We get lots of patches from Intel folks which don't have
the disclaimer at the bottom.

Sorry to delay this simple change yet again.

+full committers list and Juergen 

OK. We should have a separate discussion related to disclaimers: make a formal decision and afterwards document it in the contribution workflow. I agree that this makes sense, and this has been raised by Julien in the past privately related to questions on xen-devel@. It then turned out that Arm folks from China have consistently used disclaimers on contributions to mini-os and unikraft. This has stopped now, which is to Julien's credit. I suggested than that Julien should raise this issue formally as a policy change, which never happened.

I do not believe that we should block any patches from being applied due to disclaimers in absence of an agreed policy. Contributors sign a DCO and that may well override a disclaimer (we do not have access to the legal advice that Greg KH refers to). If there was a serious legal issue, the LF would have contacted all of its projects. And I also could not find any public reference to such an issue. This definitely something where the Advisory Board should have some input.

And in particular this patch also contains no code and should not be blocked on these grounds.

@Lukasz: please take note of this issue for the next time round. It should be easy enough to disable the disclaimer when sending to certain lists

To move forward: 

* There should be a policy discussion

* There should be AB input

* The outcome should be documented in https://xenproject.org/help/contribution-guidelines/ and the git contribution workflow

Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel