linux-kernel - Re: mfd: Patch management?

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] [day] [month] [year] [list]

Date:   Mon, 29 Jan 2018 11:15:48 +0100
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Lee Jones <lee.jones@...aro.org>, kernel-janitors@...r.kernel.org
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Lars Pöschel <poeschel@...onage.de>,
        Linus Walleij <linus.walleij@...aro.org>,
        Samuel Ortiz <sameo@...ux.intel.com>
Subject: Re: mfd: Patch management?

>> I imagine that acceptance for these changes could be influenced
>> also by review comments from other contributors.
> 
> Influenced yes, but I will also need to review them.

Yes. - This is the usual process.

> You can't 'go around' me, if that's what you're thinking.

I do not think this. - I hope somehow that additional review comments
(by other contributors) could make the handling of shown update candidates
more promising.

>> How are the chances that further update suggestions will be integrated
>> just because I sent them as small patch series in the threaded way?
>>
>> Examples:
>> * tps65910: Adjustments for four function implementations
>>   https://lkml.org/lkml/2018/1/16/313
>>
>> * abx500-core: Adjustments for eight function implementations
>>   https://lkml.org/lkml/2018/1/16/186
> 
> In order to not make my life difficult,

There are more options to make it a bit easier, aren't there?

> I've kindly requested that you gather all of your MFD patches

Or the remaining ones …?

> and send them as one single set.

Do you still insist to get these seven update steps in a bigger patch series
despite of their threaded structure?

> Is there a good reason why you're not willing to do so?

I am trying to find out if a few formal details are really hindering
progress on the clarification of affected implementation details.

I assume that additional hints could occur until I might rebase mentioned
change combinations on another recent commit.

Regards,
Markus