| Message ID | 20190725135112.83569-1-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | tboot: remove maintainers and declare orphaned | expand |
On 25/07/2019 14:51, Roger Pau Monne wrote: > Gang Wei Intel email address has been bouncing for some time now, 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 > > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
(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. > On Jul 25, 2019, at 09:51, Roger Pau Monne <roger.pau@citrix.com> 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? 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. > 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. Rich
Hi Rich, On 25/07/2019 20:08, Rich Persaud wrote: > Could you include Lukasz patch, along with Julien's requested formatting > changes, in your update to the MAINTAINERS file? 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. In general maintainers are aware of the community and the process. If that's not the case, then I am not sure it is wise to give make him the only maintainer of that subsystem. A more suitable position would be "reviewer" for the next few months with a plan to make him ultimately maintainer. Cheers,
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@citrix.com> 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. > 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. Hope this makes sense, Roger.
On 25.07.2019 21:08, Rich Persaud wrote: > 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. On top of what others have already said in response I'd like to also point out that it is the patch submitter's responsibility to chase missing ack-s. Lukasz and Shane working for the same company should have provided even better means to do so than "the Xen community having multiple communication channels with Intel". Independent of that, and somewhat in conflict with Roger's earlier reply, this model of installing maintainers doesn't really fit well with out general "meritocracy" view: Before making anyone maintainer of anything, they should have demonstrated their interest and (Xen side) knowledge. Jan
> On 26 Jul 2019, at 08:17, Roger Pau Monné <roger.pau@citrix.com> 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@citrix.com> 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
ACKed by: Shane Wang <shane.wang@intel.com> -----Original Message----- From: Roger Pau Monne [mailto:roger.pau@citrix.com] Sent: Thursday, July 25, 2019 9:51 PM To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne <roger.pau@citrix.com>; Andrew Cooper <andrew.cooper3@citrix.com>; George Dunlap <George.Dunlap@eu.citrix.com>; Ian Jackson <ian.jackson@eu.citrix.com>; Jan Beulich <jbeulich@suse.com>; Julien Grall <julien.grall@arm.com>; Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>; Stefano Stabellini <sstabellini@kernel.org>; Tim Deegan <tim@xen.org>; Wei Liu <wl@xen.org>; Gang Wei <gang.wei@intel.com>; Wang, Shane <shane.wang@intel.com> Subject: [PATCH] tboot: remove maintainers and declare orphaned Gang Wei Intel email address has been bouncing for some time now, 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 Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: George Dunlap <George.Dunlap@eu.citrix.com> Cc: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Jan Beulich <jbeulich@suse.com> Cc: Julien Grall <julien.grall@arm.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Tim Deegan <tim@xen.org> Cc: Wei Liu <wl@xen.org> Cc: Gang Wei <gang.wei@intel.com> Cc: Shane Wang <shane.wang@intel.com> --- MAINTAINERS | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4e7680934b..89a01b710b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -240,9 +240,7 @@ S: Maintained F: tools/golang INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT) -M: Gang Wei <gang.wei@intel.com> -M: Shane Wang <shane.wang@intel.com> -S: Supported +S: Orphaned F: xen/arch/x86/tboot.c F: xen/include/asm-x86/tboot.h -- 2.20.1 (Apple Git-117)
Hi Lars As you suggested, I have sent patch that added myself as TXT maintainer: https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02077.html I didn't change TXT support state to "supported", I guess that this should be done by XEN community. Thanks, Lukasz -----Original Message----- From: Lars Kurth <lars.kurth.xen@gmail.com> To: Roger Pau Monne <roger.pau@citrix.com>, Tamas K Lengyel <tamas@tklengyel.com>, Lukasz Hawrylko < lukasz.hawrylko@intel.com>, Shane Wang <shane.wang@intel.com>, Jun Nakajima <jun.nakajima@intel.com> , Rich Persaud <persaur@gmail.com> Cc: xen-devel <xen-devel@lists.xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, George Dunlap < George.Dunlap@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson < ian.jackson@eu.citrix.com>, Tim (Xen.org) <tim@xen.org>, Julien Grall <julien.grall@arm.com>, 'Jan Beulich' <jbeulich@suse.com>, tboot-devel@lists.sourceforge.net, Marek Marczykowski-Górecki < marmarek@invisiblethingslab.com>, Daniel Smith <dpsmith@apertussolutions.com> Subject: Re: [Xen-devel] [PATCH] tboot: remove maintainers and declare orphaned Date: Fri, 26 Jul 2019 17:17:22 +0100 > On 26 Jul 2019, at 08:17, Roger Pau Monné < > roger.pau@citrix.com > > 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@citrix.com > > > > 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 -------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
diff --git a/MAINTAINERS b/MAINTAINERS index 4e7680934b..89a01b710b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -240,9 +240,7 @@ S: Maintained F: tools/golang INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT) -M: Gang Wei <gang.wei@intel.com> -M: Shane Wang <shane.wang@intel.com> -S: Supported +S: Orphaned F: xen/arch/x86/tboot.c F: xen/include/asm-x86/tboot.h
Gang Wei Intel email address has been bouncing for some time now, 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 Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: George Dunlap <George.Dunlap@eu.citrix.com> Cc: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Jan Beulich <jbeulich@suse.com> Cc: Julien Grall <julien.grall@arm.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Tim Deegan <tim@xen.org> Cc: Wei Liu <wl@xen.org> Cc: Gang Wei <gang.wei@intel.com> Cc: Shane Wang <shane.wang@intel.com> --- MAINTAINERS | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)