lkml.org 
[lkml]   [2023]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] module.h: Fix full name of the GPL
From
On 1/24/23 20:32, Diederik de Haas wrote:
> *) I made a clusterfsck of similar patch submissions where I replaced "GNU
> Public License" with "GNU General Public License", and got the exact same
> comment from Bagas to several of them.

That was what I mean: not being word-for-word same, but semantically same
text. I guess everyone here (and myself) should be immersed more into
English-speaking idioms...

If you'd like to see what my reviews are, please see (in lore.kernel.org
search bar) `f:bagasdotme@gmail.com AND s:"Re:"`. Read the whole message.

> I've (now) retracted all of those patches, except this one. In those other
> ones, I later realized I would actually be changing the license, not merely
> fixing a spelling error.
> See https://lore.kernel.org/lkml/2281101.Yu7Ql3qPJb@prancing-pony/
>
> AFAICT, for this patch I'm not changing the actual license, only references to
> that license, so that can still be considered spelling fixes.
> That's why I haven't requested to ignore this patch (too).
>

OK.

>> Why did you do that? Maybe as justification for your other GPL name
>> expansion fix patches?
>
> Debian's lintian tool complained about it and after looking at
> https://www.gnu.org/licenses/ I concluded that lintian was right.
>

Nice.

> As the full/proper name of the GPL is GNU General Public License, I submitted
> a patch to fix that.
>

OK, I know the reason.

>> Anyway, let's see what Linus thinks.
>
> Sorry you all had to see my rant, but after seeing (and ignoring) Bagas'
> rather useless and exactly the same comment numerous times yesterday and
> getting accused of being a bot (!) and someone else feeling the need to point
> out Bagas' less then constructive behavior AND me feeling shitty about my
> clusterfsck and spending considerable time fixing that (which is fair)
> yesterday, it seemed Bagas went out of their way to find the one patch I hadn't
> asked to ignore and add the same useless and bot-like comment to, I had
> enough. I'm not a delicate flower which needs to be handled with extreme care,
> but everyone does have a breaking point.
>

Let's assume that I'm on the subsystem maintainer side. I receive patches from
many people (and you), including first-time contributors who has just started to
learn how to submit kernel patches. I may take more care on patch description
(which would later become commit message in the changelog) and description.
I may follow Documentation/process/submitting-patches.rst literally and check
for code correctness/look more (disclaimer: since I'm autistic and had like to
see all patches having my own quality level, i.e. raise the bar). Good developers
are expected to addresses any reviews not only from me but also others. Sometimes
I massage the patch description when I have time and motivation to do so when
applying, but I may simply want to see the reroll if I'm lazy. Other maintainers
may or may not have "harsh" requirement as mine did, but that's the life in the
kernel development: there are idiosyncrasies which can only be understood by
immersing yourself into them.

> If this patch is just wrong, please ignore it. If it needs improvement, let me
> know and I'll do my best to do so.
>

OK, thanks!

--
An old man doll... just what I always wanted! - Clara

\
 
 \ /
  Last update: 2023-03-26 23:54    [W:0.050 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site