Re: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular distinctions

[Florian Fainelli]

On 05/23/2017 05:37 PM, Scott Branden wrote:
> 
> 
> On 17-05-23 05:25 PM, Florian Fainelli wrote:
>> On 05/23/2017 05:12 PM, Paul Gortmaker wrote:
>>> [Re: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
>>> distinctions] On 23/05/2017 (Tue 15:15) Scott Branden wrote:
>>>
>>>> Hi Paul,
>>>>
>>>> Some comments - leave our file headers intact.  If you want to add a
>>>> new
>>>> comment do so after the existing file header in another comment. 
>>>> But, I
>>>> don't think any of that information is needed by us.
>>> OK, no problem, if that is what is desired for your driver.  I just
>>> normally move the author information from the bottom of the file to the
>>> top of the file.  As a lot of the linux driver work was (is?) done for
>>> kudos and not for career, I can't just delete author information.  That
>>> would not be fair to most of those contributors.
>>>
>>> It hasn't been a problem before in all of the other similar commits I've
>>> made, but I can imagine a tool that does a check on the comment block on
>>> the top of a file and complains if it changes, or similar.
>>>
>>> Would you prefer something like this instead?  It leaves your header
>>> completely untouched, and still gives credit to the original author,
>>> and those lines are also untouched.
>> This looks horrible, sorry. Scott, what's the matter with moving the
>> authors listed in MODULE_AUTHOR() into the header?
> We have tools for scanning headers.  Mucking with the headers
> is not desirable as tools may need to change.  Just place additional
> comments in new comments blocks.

That's a pretty moot explanation. These tools will have to deal with
random changes being done to the kernel as the project keeps seeing more
changes.

Plus, you may get Paul to do what you him to do here and not put
anything in the header, but there is no guarantee someone else won't be
doing it, and even if you are CC'd on the patches, what if you are not,
and what if you can't defend this "breaks our tools" position, does not
scale to me.

If it's an internal tool, it can certainly be fixed, if it's coming from
an external vendor, I'd be seriously concerned if their scanning/logic
started to break in 4.13 because Paul's patches got included...

At any rate, I'd just drop the MODULE_AUTHOR() altogether, we can use
the SCM to tell us who did what exactly in a much more powerful way
(like line by line).
-- 
Florian