MAINTAINERS: Marking internal distribution lists

MAINTAINERS: Marking internal distribution lists

[Lukas Bulwahn]

Hi Joe,

in my continued effort to clean up MAINTAINERS, I came across various 
email "lists" that are actually just some kind of internal distribution
lists, but we cannot subscribe to them (no archives available) and they 
are not affiliated to a specific person.

Some examples are:

  - bcm-kernel-feedback-list.broadcom.com
  - brcm80211-dev-list.cypress.com
  - brcm80211-dev-list.pdl.broadcom.com
  - coreteam.netfilter.org
  - esc.storagedev.microsemi.com
  - linux-imx.nxp.com
  - megaraidlinux.pdl.broadcom.com
  - MPT-FusionLinux.pdl.broadcom.com
  - ocfs2-devel.oss.oracle.com
  - oss-drivers.netronome.com
  - patches.opensource.cirrus.com
  - qat-linux.intel.com
  - rds-devel.oss.oracle.com
  - sparmaintainer.unisys.com
  - wil6210.qti.qualcomm.com
  - x86.kernel.org

One of the dots needs to be replaced by an @, of course, but let us not 
make it too easy for spammers to pick something up ;)

Some of them are mentioned in MAINTAINERS with 'L:' entry as those above, 
some others are mentioned in MAINTAINERS with an 'R:' or even a 'M:' entry.

Greg KH also called them email group aliases and does not want them to be 
valid entries for maintainer roles ('M:') because it is unclear who really 
is the maintainer for such sections (when is it orphaned, when does the 
maintainer actually change, etc.).

Would you have any recommendation for marking/handling such email 
addresses in MAINTAINERS?

I thought about the following options:

If the email address cannot be affiliated to one specific person and the 
list is not subscribable,

  A. should we then mark them as 'L: email (internal)'? (or 
     some other keyword, such as non-subscribable, restricted group...)
 
  B. should we just make them 'R:' entries?

With a bit of searching and guessing, I can probably update all those 
entries in MAINTAINERS and pass them to the according mailing lists for 
review and inclusion.


Best regards,

Lukas

Re: MAINTAINERS: Marking internal distribution lists

[Christoph Hellwig]

On Fri, Sep 11, 2020 at 08:37:54AM +0200, Lukas Bulwahn wrote:
>   - ocfs2-devel.oss.oracle.com

This is a normal mailing list, and I subscribed to it normally.  It
might howerever be brken in various ways as oss.oracle.com seems
pretty much unmaintained.

>   - rds-devel.oss.oracle.com

The same probably applies here.

Adding marting who might be able to find a contact at oracle to help
with issues with it.

Re: MAINTAINERS: Marking internal distribution lists

[Lukas Bulwahn]

On Fri, 11 Sep 2020, Christoph Hellwig wrote:

> On Fri, Sep 11, 2020 at 08:37:54AM +0200, Lukas Bulwahn wrote:
> >   - ocfs2-devel.oss.oracle.com
> 
> This is a normal mailing list, and I subscribed to it normally.  It
> might howerever be brken in various ways as oss.oracle.com seems
> pretty much unmaintained.
> 
> >   - rds-devel.oss.oracle.com
> 
> The same probably applies here.
>

Thanks, Christoph; it seems that I miscategorized those two email 
addresses in my first attempt going through the data.

I found the URLs how to subscribe to those mailing lists, so no help from 
Martin is required here.

Lukas

Re: MAINTAINERS: Marking internal distribution lists

[Joe Perches]

On Fri, 2020-09-11 at 08:37 +0200, Lukas Bulwahn wrote:
> Hi Joe,
> 
> in my continued effort to clean up MAINTAINERS, I came across various 
> email "lists" that are actually just some kind of internal distribution
> lists, but we cannot subscribe to them (no archives available) and they 
> are not affiliated to a specific person.
> 
> Some examples are:
> 
>   - bcm-kernel-feedback-list.broadcom.com
>   - brcm80211-dev-list.cypress.com
>   - brcm80211-dev-list.pdl.broadcom.com
>   - coreteam.netfilter.org
>   - esc.storagedev.microsemi.com
>   - linux-imx.nxp.com
>   - megaraidlinux.pdl.broadcom.com
>   - MPT-FusionLinux.pdl.broadcom.com
>   - ocfs2-devel.oss.oracle.com
>   - oss-drivers.netronome.com
>   - patches.opensource.cirrus.com
>   - qat-linux.intel.com
>   - rds-devel.oss.oracle.com
>   - sparmaintainer.unisys.com
>   - wil6210.qti.qualcomm.com
>   - x86.kernel.org

At one time, those sorts of email addresses were called "exploders"

Perhaps mark them as such?
Maybe like:

L:	megaraidlinux.pdl@broadcom.com (exploder for non-subscribers)

Re: MAINTAINERS: Marking internal distribution lists

[Lukas Bulwahn]

On Fri, 11 Sep 2020, Joe Perches wrote:

> On Fri, 2020-09-11 at 08:37 +0200, Lukas Bulwahn wrote:
> > Hi Joe,
> > 
> > in my continued effort to clean up MAINTAINERS, I came across various 
> > email "lists" that are actually just some kind of internal distribution
> > lists, but we cannot subscribe to them (no archives available) and they 
> > are not affiliated to a specific person.
> > 
> > Some examples are:
> > 
> >   - bcm-kernel-feedback-list.broadcom.com
> >   - brcm80211-dev-list.cypress.com
> >   - brcm80211-dev-list.pdl.broadcom.com
> >   - coreteam.netfilter.org
> >   - esc.storagedev.microsemi.com
> >   - linux-imx.nxp.com
> >   - megaraidlinux.pdl.broadcom.com
> >   - MPT-FusionLinux.pdl.broadcom.com
> >   - ocfs2-devel.oss.oracle.com
> >   - oss-drivers.netronome.com
> >   - patches.opensource.cirrus.com
> >   - qat-linux.intel.com
> >   - rds-devel.oss.oracle.com
> >   - sparmaintainer.unisys.com
> >   - wil6210.qti.qualcomm.com
> >   - x86.kernel.org
> 
> At one time, those sorts of email addresses were called "exploders"
> 
> Perhaps mark them as such?
> Maybe like:
> 
> L:	megaraidlinux.pdl@broadcom.com (exploder for non-subscribers)
> 

It is a bit long, but sounds good to me.

If that is still the terminology to settle for, I will send out patches to 
update the description and data in MAINTAINERS.

Lukas

Re: MAINTAINERS: Marking internal distribution lists

[Martin K. Petersen]

Christoph,

> On Fri, Sep 11, 2020 at 08:37:54AM +0200, Lukas Bulwahn wrote:

>>   - ocfs2-devel.oss.oracle.com
>>   - rds-devel.oss.oracle.com

Both of these are public development lists and should be fully
functional, have archives available, etc. Let me know if that's not the
case.

-- 
Martin K. Petersen	Oracle Linux Engineering