Virtualization - Nov 2021 - [PATCH v3 1/3] MAINTAINERS: Update maintainers for paravirt ops and VMware hypervisor interface

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 at
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 at
csail.mit.edu>
> > > > Acked-by: Alexey Makhalov <amakhalov at vmware.com>
> > > > Acked-by: Deep Shah <sdeep at vmware.com>
> > > > Acked-by: Juergen Gross <jgross at suse.com>
> > > > Cc: stable at 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 at
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
at csail.mit.edu>
> > > > > Acked-by: Alexey Makhalov <amakhalov at
vmware.com>
> > > > > Acked-by: Deep Shah <sdeep at vmware.com>
> > > > > Acked-by: Juergen Gross <jgross at suse.com>
> > > > > Cc: stable at 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 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 at
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 at
csail.mit.edu>
>> > > > Acked-by: Alexey Makhalov <amakhalov at
vmware.com>
>> > > > Acked-by: Deep Shah <sdeep at vmware.com>
>> > > > Acked-by: Juergen Gross <jgross at suse.com>
>> > > > Cc: stable at 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.

-- 
Thanks,
Sasha