Re: [PATCH v2] MAINTAINERS: Remove D. Kershner from Unisys S-PAR maintainers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On marted? 12 aprile 2022 12:41:27 CEST Greg Kroah-Hartman wrote:
> On Tue, Apr 12, 2022 at 12:36:29PM +0200, Fabio M. De Francesco wrote:
> > The email address of David Kershner is no more reachable. Remove his
> > entry from the MAINTAINERS file for UNISYS S-PAR DRIVERS and change
> > the status to "Orphan".
> > 
> > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@xxxxxxxxx>
> > ---
> > 
> > v1->v2: Change also the status of the entry to "Orphan" and rework the
> > commit message. (Thanks to Greg Kroah-Hartman).
> > 
> >  MAINTAINERS | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 3ed62dcd144e..9283c63565b3 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -20184,9 +20184,8 @@ F:	include/linux/cdrom.h
> >  F:	include/uapi/linux/cdrom.h
> >  
> >  UNISYS S-PAR DRIVERS
> > -M:	David Kershner <david.kershner@xxxxxxxxxx>
> >  L:	sparmaintainer@xxxxxxxxxx (Unisys internal)
> 
> Again, please drop this "list" as it obviously is not going to anyone.

OK, I'll also drop the "L:" line. I wasn't sure about it because I see 
that there are other entries marked as "Orphan" and the list is still
there. But you are right: although the "sparmaintainer" list address is
not bouncing, it looks like nobody care to read messages there.
  
> And really, this whole code should be removed, no one seems to be using
> it, and if they are, we can easily revert the removal and mark them as
> the maintainer.

1) If I remove the entire drivers/staging/unisys/ I suppose that, in 
MAINTAINERS I should also remove the whole entry called "UNISYS S-PAR 
DRIVERS", not only the "L:" line. 

2) Furthermore, I understand that I should also should change the relevant 
Kbuild files, otherwise all builds of staging would fail. 

I'm sorry for asking but, as you probably recall, I have no prior experience 
with removing drivers from trees and with the Kbuild's infrastructure. I'll 
take some time to read how it works.

Are the two arguments above correct?

Thanks,

Fabio M. De Francesco







[Index of Archives]     [Linux Driver Development]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux