> On 30 Jul 2019, at 11:08, George Dunlap <george.dun...@citrix.com> 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.hawry...@intel.com> >>>>>> --- >>>>>> 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.hawry...@intel.com> >>>>>> +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/ <https://xenproject.org/help/contribution-guidelines/> and the git contribution workflow Lars
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
