Re: [Xen-devel] [PATCH] tboot: remove maintainers and declare orphaned

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

> On 26 Jul 2019, at 08:17, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> 
> On Thu, Jul 25, 2019 at 03:08:07PM -0400, Rich Persaud wrote:
>> (cc Intel and tboot-devel)
>> 
>> Hi Roger,
>> 
>> Thanks for your interest in documenting the status of maintenance for Intel 
>> TXT support in Xen.  Intel TXT and Xen are deployed in production today by 
>> OpenXT and QubesOS for boot integrity.  Xen was a pioneering adopter of 
>> DRTM, almost a decade ago, but mainstream enterprise computing is now 
>> catching up with the May 2019 release of Windows 10 SystemGuard.  It would 
>> be nice to avoid "orphaning" one of Xen's competitive advantages in 2019.
> 
> Thanks for the feedback! Just to be clear, this is not a plan to
> remove the tboot code from Xen in any way, it's just a IMO needed step
> in order to reflect the current maintainership status of the code, and
> likely a way to move forward, please see below.


>>> On Jul 25, 2019, at 09:51, Roger Pau Monne <roger.pau@xxxxxxxxxx> wrote:
>>> 
>>> Gang Wei Intel email address has been bouncing for some time now,
>> 
>> Gang Wei's replacement is Lukasz Hawrylko, who posted on March 6, 2019:
>> https://lists.gt.net/xen/devel/546401
>> 
>> Could you include Lukasz patch, along with Julien's requested formatting 
>> changes, in your update to the MAINTAINERS file?
> 
> I think it would be better if Lukasz could resend his patch, now that
> the section entry is orphaned we can add/remove reviewers and
> maintainers without being blocked.

I added Tamas who I believe works for Intel in the security area and maybe he 
can connect some dots here. I believe that Intel's security organisation is 
entirely different from our normal interfaces with Intel, so he may be able to 
help. 

@Lukasz: could you re-send the patch related to maintainership after the patch 
has been applied? Regarding Jan's and Julien's concerns about awarding 
maintainership straight away. We tend to ask prospective maintainers who don't 
have a track record of reviewing code in the community to start as reviewers. 
An example of this is the VM EVENT, MEM ACCESS and MONITOR component where 
Razvan is handing over maintainership to two other bitdefender staff members. 
In practice, this makes not a lot of difference if you review contributions to 
TXT. 

Regarding removing Shane Wang as maintainer, the case for this is somewhat 
stronger than simply not replying to [0]. The last mail Shane sent to 
xen-devel@ was in 2011. This - according to his LinkedIn profile - relates to a 
career change towards becoming a manager and being responsible for components 
that are not related to virtualisation. Shane should probably have stepped down 
as a maintainer pro-actively, but we normally don't remove maintainers unless 
there is a problem. Clearly the lack of a responsive maintainer is now a 
problem: we already have been unable to instate Lukasz as maintainer in March 
for that reason as technically an ACK from an existing maintainer is needed.

@Roger: this should be recorded in the commit message. I would also suggest you 
refer to the thread related to Lukasz taking over maintainership, which was 
essentially blocked because Gang had probably sent the maintainership change 
request too late and couldn't ACK it because he probably didn't have access to 
his Intel email address anymore.

So I think removing Shane is fair enough. In particular if it helps instate a 
replacement maintainer. 

>> As a new Xen maintainer and contributor, Lukasz may not yet be familiar with 
>> the procedures and practices of the Xen community.  We can welcome his new 
>> maintainership role without dropping support for a feature, that (a) he is 
>> maintaining, (b) is used by Xen.
> 
> Sure, my plan is to declare the support orphaned, so that Lukasz (or
> anyone who has interest in this code) can be added as a reviewer
> afterwards without us being blocked on an Ack from Shane Wang, who is
> unresponsive (as per the thread pointed to in the commit message).


>>> and
>>> the other maintainer is non-responsive to patches [0], so remove
>>> maintainers and declare INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
>>> orphaned.
>>> 
>>> [0] 
>>> https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg00563.html
>> 
>> Since we have at least one Intel maintainer, Lukasz, the feature need not be 
>> orphaned.  If Shawn is not responding to the request to confirm Lukasz as 
>> maintainer, the Xen community has multiple communication channels with 
>> Intel.  Pragmatically, a review of the tboot-devel archives shows that 
>> Lukasz is working on tboot development.  
> 
> The orphaned step is IMO needed in order to move forward and add a new
> reviewer/maintainer. Without removing the current maintainers and
> declaring it orphaned we would be blocked on an Ack from Shane Wang in
> order to add or remove maintainers. Removing current maintainers and
> adding Lukasz in the same patch would still require an Ack from the
> current owners.

@All: we probably need to look at the hand-over of maintainership, given this 
issue. We should really not be in this position and should have a way to deal 
with this in a more efficient way. 


Best Regards
Lars


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