This series updates a few maintainer entries for VMware-maintained subsystems and cleans up references to VMware's private mailing lists to make it clear that they are effectively email-aliases to reach out to reviewers.
Changes from v1->v3: - Add Zack as the named maintainer for vmmouse driver - Use R: to denote email-aliases for VMware reviewers
Regards, Srivatsa
---
Srivatsa S. Bhat (VMware) (3): MAINTAINERS: Update maintainers for paravirt ops and VMware hypervisor interface MAINTAINERS: Add Zack as maintainer of vmmouse driver MAINTAINERS: Mark VMware mailing list entries as email aliases
MAINTAINERS | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-)
From: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu
Deep has decided to transfer maintainership of the VMware hypervisor interface to Srivatsa, and the joint-maintainership of paravirt ops in the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file to reflect this change.
Signed-off-by: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu Acked-by: Alexey Makhalov amakhalov@vmware.com Acked-by: Deep Shah sdeep@vmware.com Acked-by: Juergen Gross jgross@suse.com Cc: stable@vger.kernel.org ---
MAINTAINERS | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS index 0ad926ba362f..0329d67c5bcf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14188,7 +14188,7 @@ F: include/uapi/linux/ppdev.h
PARAVIRT_OPS INTERFACE M: Juergen Gross jgross@suse.com -M: Deep Shah sdeep@vmware.com +M: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu M: "VMware, Inc." pv-drivers@vmware.com L: virtualization@lists.linux-foundation.org L: x86@kernel.org @@ -20038,10 +20038,13 @@ S: Maintained F: drivers/misc/vmw_balloon.c
VMWARE HYPERVISOR INTERFACE -M: Deep Shah sdeep@vmware.com +M: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu +M: Alexey Makhalov amakhalov@vmware.com M: "VMware, Inc." pv-drivers@vmware.com L: virtualization@lists.linux-foundation.org +L: x86@kernel.org S: Supported +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/vmware F: arch/x86/include/asm/vmware.h F: arch/x86/kernel/cpu/vmware.c
On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote:
From: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu
Deep has decided to transfer maintainership of the VMware hypervisor interface to Srivatsa, and the joint-maintainership of paravirt ops in the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file to reflect this change.
Signed-off-by: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu Acked-by: Alexey Makhalov amakhalov@vmware.com Acked-by: Deep Shah sdeep@vmware.com Acked-by: Juergen Gross jgross@suse.com Cc: stable@vger.kernel.org
Why are MAINTAINERS updates needed for stable? That's not normal :(
On Thu, 11 Nov 2021 07:50:39 +0100 Greg KH gregkh@linuxfoundation.org wrote:
Signed-off-by: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu Acked-by: Alexey Makhalov amakhalov@vmware.com Acked-by: Deep Shah sdeep@vmware.com Acked-by: Juergen Gross jgross@suse.com Cc: stable@vger.kernel.org
Why are MAINTAINERS updates needed for stable? That's not normal :(
Probably not needed, but does it hurt? And who's normal?
-- Steve
On Thu, Nov 11, 2021 at 07:50:39AM +0100, Greg KH wrote:
On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote:
From: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu
Deep has decided to transfer maintainership of the VMware hypervisor interface to Srivatsa, and the joint-maintainership of paravirt ops in the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file to reflect this change.
Signed-off-by: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu Acked-by: Alexey Makhalov amakhalov@vmware.com Acked-by: Deep Shah sdeep@vmware.com Acked-by: Juergen Gross jgross@suse.com Cc: stable@vger.kernel.org
Why are MAINTAINERS updates needed for stable? That's not normal :(
So that people posting bug-fixes / backports to these subsystems for older kernels (stable and LTS releases) will CC the new subsystem maintainers. That's why I added CC stable tag only to the first two patches which add/replace maintainers and not the third patch which is just a cleanup.
Regards, Srivatsa
On Thu, Nov 11, 2021 at 07:39:16AM -0800, Srivatsa S. Bhat wrote:
On Thu, Nov 11, 2021 at 07:50:39AM +0100, Greg KH wrote:
On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote:
From: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu
Deep has decided to transfer maintainership of the VMware hypervisor interface to Srivatsa, and the joint-maintainership of paravirt ops in the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file to reflect this change.
Signed-off-by: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu Acked-by: Alexey Makhalov amakhalov@vmware.com Acked-by: Deep Shah sdeep@vmware.com Acked-by: Juergen Gross jgross@suse.com Cc: stable@vger.kernel.org
Why are MAINTAINERS updates needed for stable? That's not normal :(
So that people posting bug-fixes / backports to these subsystems for older kernels (stable and LTS releases) will CC the new subsystem maintainers.
That's not how stable releases work at all.
That's why I added CC stable tag only to the first two patches which add/replace maintainers and not the third patch which is just a cleanup.
Patches for stable kernels need to go into Linus's tree first, and if you have the MAINTAINERS file updated properly there, then you will be properly cc:ed. We do not look at the MAINTAINERS file for the older kernel when sending patches out, it's totally ignored as that was the snapshot at a point in time, which is usually no longer the true state.
So this would have no affect at all, sorry. That's why I asked if you all really realized what you were doing here :)
thanks,
greg k-h
On Thu, Nov 11, 2021 at 07:45:02PM +0100, Greg KH wrote:
On Thu, Nov 11, 2021 at 07:39:16AM -0800, Srivatsa S. Bhat wrote:
On Thu, Nov 11, 2021 at 07:50:39AM +0100, Greg KH wrote:
On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote:
From: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu
Deep has decided to transfer maintainership of the VMware hypervisor interface to Srivatsa, and the joint-maintainership of paravirt ops in the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file to reflect this change.
Signed-off-by: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu Acked-by: Alexey Makhalov amakhalov@vmware.com Acked-by: Deep Shah sdeep@vmware.com Acked-by: Juergen Gross jgross@suse.com Cc: stable@vger.kernel.org
Why are MAINTAINERS updates needed for stable? That's not normal :(
So that people posting bug-fixes / backports to these subsystems for older kernels (stable and LTS releases) will CC the new subsystem maintainers.
That's not how stable releases work at all.
That's why I added CC stable tag only to the first two patches which add/replace maintainers and not the third patch which is just a cleanup.
Patches for stable kernels need to go into Linus's tree first, and if you have the MAINTAINERS file updated properly there, then you will be properly cc:ed. We do not look at the MAINTAINERS file for the older kernel when sending patches out, it's totally ignored as that was the snapshot at a point in time, which is usually no longer the true state.
Sure, but that's the case for patches that get mainlined (and subsequently backported to -stable) /after/ this update to the MAINTAINERS file gets merged into mainline.
When adding the CC stable tag, the case I was trying to address was for patches that are already in mainline but weren't CC'ed to stable, and at some later point, somebody decides to backport them to older stable kernels. In that case, there is a chance that the contributor might run ./get_maintainer.pl against the stable tree (as that's the tree they are backporting the upstream commit against) and end up not CC'ing the new maintainers. So, I thought it would be good to keep the maintainer info updated in the older stable kernels too.
Regards, Srivatsa
On Thu, Nov 11, 2021 at 11:40:02AM -0800, Srivatsa S. Bhat wrote:
On Thu, Nov 11, 2021 at 07:45:02PM +0100, Greg KH wrote:
On Thu, Nov 11, 2021 at 07:39:16AM -0800, Srivatsa S. Bhat wrote:
On Thu, Nov 11, 2021 at 07:50:39AM +0100, Greg KH wrote:
On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote:
From: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu
Deep has decided to transfer maintainership of the VMware hypervisor interface to Srivatsa, and the joint-maintainership of paravirt ops in the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file to reflect this change.
Signed-off-by: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu Acked-by: Alexey Makhalov amakhalov@vmware.com Acked-by: Deep Shah sdeep@vmware.com Acked-by: Juergen Gross jgross@suse.com Cc: stable@vger.kernel.org
Why are MAINTAINERS updates needed for stable? That's not normal :(
So that people posting bug-fixes / backports to these subsystems for older kernels (stable and LTS releases) will CC the new subsystem maintainers.
That's not how stable releases work at all.
That's why I added CC stable tag only to the first two patches which add/replace maintainers and not the third patch which is just a cleanup.
Patches for stable kernels need to go into Linus's tree first, and if you have the MAINTAINERS file updated properly there, then you will be properly cc:ed. We do not look at the MAINTAINERS file for the older kernel when sending patches out, it's totally ignored as that was the snapshot at a point in time, which is usually no longer the true state.
Sure, but that's the case for patches that get mainlined (and subsequently backported to -stable) /after/ this update to the MAINTAINERS file gets merged into mainline.
When adding the CC stable tag, the case I was trying to address was for patches that are already in mainline but weren't CC'ed to stable, and at some later point, somebody decides to backport them to older stable kernels. In that case, there is a chance that the contributor might run ./get_maintainer.pl against the stable tree (as that's the tree they are backporting the upstream commit against) and end up not CC'ing the new maintainers. So, I thought it would be good to keep the maintainer info updated in the older stable kernels too.
I always ask that the current maintainers of the code be cc:ed when asking for commits to be backported to the stable tree, so I think this is not something you need to worry about. I don't want to have to deal with hundreds of patches to try to keep the MAINTAINERS file "up to date" for this very very rare event.
You can prove me wrong by looking at our email archives and see where I have missed ever doing this in the past 18 years and what the frequency of it is...
But for now, no, this is not stable kernel material.
thanks,
greg k-h
On Fri, Nov 12, 2021 at 07:55:14AM +0100, Greg KH wrote:
On Thu, Nov 11, 2021 at 11:40:02AM -0800, Srivatsa S. Bhat wrote:
On Thu, Nov 11, 2021 at 07:45:02PM +0100, Greg KH wrote:
On Thu, Nov 11, 2021 at 07:39:16AM -0800, Srivatsa S. Bhat wrote:
On Thu, Nov 11, 2021 at 07:50:39AM +0100, Greg KH wrote:
On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote:
From: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu
Deep has decided to transfer maintainership of the VMware hypervisor interface to Srivatsa, and the joint-maintainership of paravirt ops in the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file to reflect this change.
Signed-off-by: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu Acked-by: Alexey Makhalov amakhalov@vmware.com Acked-by: Deep Shah sdeep@vmware.com Acked-by: Juergen Gross jgross@suse.com Cc: stable@vger.kernel.org
Why are MAINTAINERS updates needed for stable? That's not normal :(
So that people posting bug-fixes / backports to these subsystems for older kernels (stable and LTS releases) will CC the new subsystem maintainers.
That's not how stable releases work at all.
That's why I added CC stable tag only to the first two patches which add/replace maintainers and not the third patch which is just a cleanup.
Patches for stable kernels need to go into Linus's tree first, and if you have the MAINTAINERS file updated properly there, then you will be properly cc:ed. We do not look at the MAINTAINERS file for the older kernel when sending patches out, it's totally ignored as that was the snapshot at a point in time, which is usually no longer the true state.
Sure, but that's the case for patches that get mainlined (and subsequently backported to -stable) /after/ this update to the MAINTAINERS file gets merged into mainline.
When adding the CC stable tag, the case I was trying to address was for patches that are already in mainline but weren't CC'ed to stable, and at some later point, somebody decides to backport them to older stable kernels. In that case, there is a chance that the contributor might run ./get_maintainer.pl against the stable tree (as that's the tree they are backporting the upstream commit against) and end up not CC'ing the new maintainers. So, I thought it would be good to keep the maintainer info updated in the older stable kernels too.
I always ask that the current maintainers of the code be cc:ed when asking for commits to be backported to the stable tree, so I think this is not something you need to worry about. I don't want to have to deal with hundreds of patches to try to keep the MAINTAINERS file "up to date" for this very very rare event.
Sounds good, thank you!
You can prove me wrong by looking at our email archives and see where I have missed ever doing this in the past 18 years and what the frequency of it is...
I believe you :-)
But for now, no, this is not stable kernel material.
I understand, and thank you for the clarification!
Regards, Srivatsa
On Thu, Nov 11, 2021 at 11:40:02AM -0800, Srivatsa S. Bhat wrote:
On Thu, Nov 11, 2021 at 07:45:02PM +0100, Greg KH wrote:
On Thu, Nov 11, 2021 at 07:39:16AM -0800, Srivatsa S. Bhat wrote:
On Thu, Nov 11, 2021 at 07:50:39AM +0100, Greg KH wrote:
On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote:
From: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu
Deep has decided to transfer maintainership of the VMware hypervisor interface to Srivatsa, and the joint-maintainership of paravirt ops in the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file to reflect this change.
Signed-off-by: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu Acked-by: Alexey Makhalov amakhalov@vmware.com Acked-by: Deep Shah sdeep@vmware.com Acked-by: Juergen Gross jgross@suse.com Cc: stable@vger.kernel.org
Why are MAINTAINERS updates needed for stable? That's not normal :(
So that people posting bug-fixes / backports to these subsystems for older kernels (stable and LTS releases) will CC the new subsystem maintainers.
That's not how stable releases work at all.
That's why I added CC stable tag only to the first two patches which add/replace maintainers and not the third patch which is just a cleanup.
Patches for stable kernels need to go into Linus's tree first, and if you have the MAINTAINERS file updated properly there, then you will be properly cc:ed. We do not look at the MAINTAINERS file for the older kernel when sending patches out, it's totally ignored as that was the snapshot at a point in time, which is usually no longer the true state.
Sure, but that's the case for patches that get mainlined (and subsequently backported to -stable) /after/ this update to the MAINTAINERS file gets merged into mainline.
When adding the CC stable tag, the case I was trying to address was for patches that are already in mainline but weren't CC'ed to stable, and at some later point, somebody decides to backport them to older stable kernels. In that case, there is a chance that the contributor might run ./get_maintainer.pl against the stable tree (as that's the tree they are backporting the upstream commit against) and end up not CC'ing the new maintainers. So, I thought it would be good to keep the maintainer info updated in the older stable kernels too.
If you look at cases like these, I can see an argument around bringing it back to -stable. However, changes in the upstream MAINTAINERS file aren't limited to just change in maintainers.
How would we handle addition of maintainers of a new code upstream? Or removal of maintainers due to code deletion? Or code movement upstream that isn't reflected in the stable tree (think a driver graduating from staging).
It becomes a mess quite quickly and the easiest solution here is to just use upstream's MAINTAINERS file.
Maybe we should just remove MAINTAINERS from stable trees to make it obvious.
On Fri, Nov 12, 2021 at 12:16:53PM -0500, Sasha Levin wrote:
On Thu, Nov 11, 2021 at 11:40:02AM -0800, Srivatsa S. Bhat wrote:
On Thu, Nov 11, 2021 at 07:45:02PM +0100, Greg KH wrote:
On Thu, Nov 11, 2021 at 07:39:16AM -0800, Srivatsa S. Bhat wrote:
On Thu, Nov 11, 2021 at 07:50:39AM +0100, Greg KH wrote:
On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote:
From: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu
Deep has decided to transfer maintainership of the VMware hypervisor interface to Srivatsa, and the joint-maintainership of paravirt ops in the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file to reflect this change.
Signed-off-by: Srivatsa S. Bhat (VMware) srivatsa@csail.mit.edu Acked-by: Alexey Makhalov amakhalov@vmware.com Acked-by: Deep Shah sdeep@vmware.com Acked-by: Juergen Gross jgross@suse.com Cc: stable@vger.kernel.org
Why are MAINTAINERS updates needed for stable? That's not normal :(
So that people posting bug-fixes / backports to these subsystems for older kernels (stable and LTS releases) will CC the new subsystem maintainers.
That's not how stable releases work at all.
That's why I added CC stable tag only to the first two patches which add/replace maintainers and not the third patch which is just a cleanup.
Patches for stable kernels need to go into Linus's tree first, and if you have the MAINTAINERS file updated properly there, then you will be properly cc:ed. We do not look at the MAINTAINERS file for the older kernel when sending patches out, it's totally ignored as that was the snapshot at a point in time, which is usually no longer the true state.
Sure, but that's the case for patches that get mainlined (and subsequently backported to -stable) /after/ this update to the MAINTAINERS file gets merged into mainline.
When adding the CC stable tag, the case I was trying to address was for patches that are already in mainline but weren't CC'ed to stable, and at some later point, somebody decides to backport them to older stable kernels. In that case, there is a chance that the contributor might run ./get_maintainer.pl against the stable tree (as that's the tree they are backporting the upstream commit against) and end up not CC'ing the new maintainers. So, I thought it would be good to keep the maintainer info updated in the older stable kernels too.
If you look at cases like these, I can see an argument around bringing it back to -stable. However, changes in the upstream MAINTAINERS file aren't limited to just change in maintainers.
How would we handle addition of maintainers of a new code upstream? Or removal of maintainers due to code deletion? Or code movement upstream that isn't reflected in the stable tree (think a driver graduating from staging).
Good point!
It becomes a mess quite quickly and the easiest solution here is to just use upstream's MAINTAINERS file.
Agreed.
Maybe we should just remove MAINTAINERS from stable trees to make it obvious.
I don't think we should go quite that far. Instead, perhaps we can modify get_maintainer.pl (if needed) such that it prints out a warning or reminder to consult the upstream MAINTAINERS file if the script is invoked on an older stable kernel.
Regards, Srivatsa
On Mon, 2021-11-15 at 14:39 -0800, Srivatsa S. Bhat wrote:
On Fri, Nov 12, 2021 at 12:16:53PM -0500, Sasha Levin wrote:
Maybe we should just remove MAINTAINERS from stable trees to make it obvious.
I don't think we should go quite that far. Instead, perhaps we can modify get_maintainer.pl (if needed) such that it prints out a warning or reminder to consult the upstream MAINTAINERS file if the script is invoked on an older stable kernel.
I don't see how that's feasible.
On Mon, Nov 15, 2021 at 08:33:40PM -0800, Joe Perches wrote:
On Mon, 2021-11-15 at 14:39 -0800, Srivatsa S. Bhat wrote:
On Fri, Nov 12, 2021 at 12:16:53PM -0500, Sasha Levin wrote:
Maybe we should just remove MAINTAINERS from stable trees to make it obvious.
I don't think we should go quite that far. Instead, perhaps we can modify get_maintainer.pl (if needed) such that it prints out a warning or reminder to consult the upstream MAINTAINERS file if the script is invoked on an older stable kernel.
I don't see how that's feasible.
Not that I'm pushing for this change, but isn't it straight-forward to distinguish upstream and stable kernel releases based on their versioning schemes? The SUBLEVEL in the Makefile is always 0 for upstream, and positive for stable versions (ignoring ancient kernels like v2.6.32, of course). Since stable kernels are behind mainline by definition, anytime the get_maintainer.pl script is invoked on a kernel with a positive SUBLEVEL value, we can print out the said warning/reminder (if it is considered useful).
Regards, Srivatsa
On Tue, 2021-11-16 at 10:18 -0800, Srivatsa S. Bhat wrote:
On Mon, Nov 15, 2021 at 08:33:40PM -0800, Joe Perches wrote:
On Mon, 2021-11-15 at 14:39 -0800, Srivatsa S. Bhat wrote:
On Fri, Nov 12, 2021 at 12:16:53PM -0500, Sasha Levin wrote:
Maybe we should just remove MAINTAINERS from stable trees to make it obvious.
I don't think we should go quite that far. Instead, perhaps we can modify get_maintainer.pl (if needed) such that it prints out a warning or reminder to consult the upstream MAINTAINERS file if the script is invoked on an older stable kernel.
I don't see how that's feasible.
Not that I'm pushing for this change, but isn't it straight-forward to distinguish upstream and stable kernel releases based on their versioning schemes? The SUBLEVEL in the Makefile is always 0 for upstream, and positive for stable versions (ignoring ancient kernels like v2.6.32, of course). Since stable kernels are behind mainline by definition, anytime the get_maintainer.pl script is invoked on a kernel with a positive SUBLEVEL value, we can print out the said warning/reminder (if it is considered useful).
checkpatch doesn't work on trees, it works on patches.
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Joe Perches -
Sasha Levin -
Srivatsa S. Bhat -
Steven Rostedt