lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 26 Jun 2018 19:29:33 -0400
From:   Prarit Bhargava <prarit@...hat.com>
To:     Joe Perches <joe@...ches.com>, linux-kernel@...r.kernel.org
Cc:     dzickus@...hat.com, jtoppins@...hat.com
Subject: Re: [PATCH] get_maintainer.pl: Add optional
 .get_maintainer.MAINTAINERS override



On 06/26/2018 07:04 PM, Joe Perches wrote:
> On Tue, 2018-06-26 at 18:52 -0400, Prarit Bhargava wrote:
>>
>> On 06/26/2018 04:16 PM, Joe Perches wrote:
>>> On Tue, 2018-06-26 at 14:25 -0400, Prarit Bhargava wrote:
>>>> OSes have additional maintainers that should be cc'd on patches or may
>>>> want to circulate internal patches.
>>>>
>>>> Parse the .get_maintainer.MAINTAINERS file.  Entries in the file
>>>> can begin with a '+' to indicate the email and list entries should be
>>>> added to the exiting MAINTAINERS output, or a '-' to indicate that the
>>>> entries should override the existing MAINTAINERS file.
>>>>
>>>> Also add a help entry for the .get_maintainers.ignore file.
>>>
>>> I see no reason for this patch to be applied.
>>> Why should it?
>>
>> The kernel has other vendor/OS changes like my patch, for example, 4efb442cc12e
>> ("kernel/panic.c: add TAINT_AUX").  From that commit message
>>
>>     Add an auxiliary taint flag to be used by distros and others.  This
>>     obviates the need to forward-port whatever internal solutions people
>>     have in favor of a single flag which they can map arbitrarily to a
>>     definition of their pleasing.
>>
>> The same principle should be applied to my patch in that distros no longer would
>> need to forward-port internal solutions similar to this.
>>
>>> Why shouldn't this be in your private repository?
>>
>> If you don't want it I'll carry it forward but that's a loss for both of us, and
>> as pointed out in the above commit, other distros.  If you do want to reject the
>> patch please let me know and I'll only submit the "get_maintainer.ignore" help
>> chunk.
> 
> I doubt it's a really a loss for others as whatever
> .get_maintainers.<foo> files would likely need to
> be customized for each distro.

That's the point of the patch.  Each distro would customize their own internal
.get_maintainers.MAINTAINERS file.

In any case, consider it dropped.

P.

> 
> I think the whole thing should be ignored.
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ