Signed-off-by: Diederik de Haas <[email protected]>
---
include/linux/module.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 8c5909c0076c..329fa0b56642 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -186,14 +186,14 @@ extern void cleanup_module(void);
* The following license idents are currently accepted as indicating free
* software modules
*
- * "GPL" [GNU Public License v2]
- * "GPL v2" [GNU Public License v2]
- * "GPL and additional rights" [GNU Public License v2 rights and more]
- * "Dual BSD/GPL" [GNU Public License v2
+ * "GPL" [GNU General Public License v2]
+ * "GPL v2" [GNU General Public License v2]
+ * "GPL and additional rights" [GNU General Public License v2 rights and more]
+ * "Dual BSD/GPL" [GNU General Public License v2
* or BSD license choice]
- * "Dual MIT/GPL" [GNU Public License v2
+ * "Dual MIT/GPL" [GNU General Public License v2
* or MIT license choice]
- * "Dual MPL/GPL" [GNU Public License v2
+ * "Dual MPL/GPL" [GNU General Public License v2
* or Mozilla license choice]
*
* The following other idents are available
--
2.39.0
On Sun, Jan 22, 2023 at 08:34:43PM +0100, Diederik de Haas wrote:
> Signed-off-by: Diederik de Haas <[email protected]>
No patch description, really?
> ---
> include/linux/module.h | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 8c5909c0076c..329fa0b56642 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -186,14 +186,14 @@ extern void cleanup_module(void);
> * The following license idents are currently accepted as indicating free
> * software modules
> *
> - * "GPL" [GNU Public License v2]
> - * "GPL v2" [GNU Public License v2]
> - * "GPL and additional rights" [GNU Public License v2 rights and more]
> - * "Dual BSD/GPL" [GNU Public License v2
> + * "GPL" [GNU General Public License v2]
> + * "GPL v2" [GNU General Public License v2]
> + * "GPL and additional rights" [GNU General Public License v2 rights and more]
> + * "Dual BSD/GPL" [GNU General Public License v2
> * or BSD license choice]
> - * "Dual MIT/GPL" [GNU Public License v2
> + * "Dual MIT/GPL" [GNU General Public License v2
> * or MIT license choice]
> - * "Dual MPL/GPL" [GNU Public License v2
> + * "Dual MPL/GPL" [GNU General Public License v2
> * or Mozilla license choice]
> *
> * The following other idents are available
Why did you do that? Maybe as justification for your other GPL name expansion
fix patches?
Anyway, let's see what Linus thinks.
--
An old man doll... just what I always wanted! - Clara
On Tuesday, 24 January 2023 03:49:02 CET Bagas Sanjaya wrote:
> On Sun, Jan 22, 2023 at 08:34:43PM +0100, Diederik de Haas wrote:
> > Signed-off-by: Diederik de Haas <[email protected]>
>
> No patch description, really?
Writing the exact same comment 5+ times ... really? *
You might take inspiration from Greg's bot, which clearly identifies itself as
being a bot, is WAY more friendly and actually useful as it points out why
it's wrong and where I can find out how to improve it.
Your messages were none of that.
While I should have, but hadn't read "The canonical patch format" section
Greg's bot pointed to, it turns out that my own common sense/practice didn't
violate it. I'm a HUGE proponent of extended commit messages and often try to
convince others to do so too, often pointing to the linux kernel to take
inspiration from.
"The explanation body will be committed to the permanent source
changelog, so should make sense to a competent reader who has long since
forgotten the immediate details of the discussion that might have led to
this patch."
So it should add context for people who'd see the patch months/years down the
line. As the Subject/summary phrase rarely is capable of providing the
*needed* context, that's highly useful and valuable.
In this case, the patch is simple and IMO the Subject already contains all the
details one need have to understand this patch 5 years from now.
So I could've added "The full name of the GPL is not GNU Public License, but
GNU *General* Public License." to/as the explanation body, but I didn't
consider that to provide extra (needed) info which wasn't clear from the
Subject and diff.
My only previous patch submission (to the linux kernel) did contain a full
explanation body: 7074b39d83f5d71fa4f0521b28bd4fb3a22152c1
*) 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.
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).
> > include/linux/module.h | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index 8c5909c0076c..329fa0b56642 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -186,14 +186,14 @@ extern void cleanup_module(void);
> >
> > * The following license idents are currently accepted as indicating free
> > * software modules
> > *
> >
> > - * "GPL" [GNU Public License v2]
> > - * "GPL v2" [GNU Public License v2]
> > - * "GPL and additional rights" [GNU Public License v2
> > rights and more]
> > - * "Dual BSD/GPL" [GNU Public License v2
> > + * "GPL" [GNU General Public License v2]
> > + * "GPL v2" [GNU General Public License v2]
> > + * "GPL and additional rights" [GNU General Public License
> > v2 rights and
> > more] + * "Dual BSD/GPL" [GNU General Public License v2
> >
> > * or BSD license choice]
> >
> > - * "Dual MIT/GPL" [GNU Public License v2
> > + * "Dual MIT/GPL" [GNU General Public License v2
> >
> > * or MIT license choice]
> >
> > - * "Dual MPL/GPL" [GNU Public License v2
> > + * "Dual MPL/GPL" [GNU General Public License v2
> >
> > * or Mozilla license choice]
> > *
> > * The following other idents are available
>
> 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.
As the full/proper name of the GPL is GNU General Public License, I submitted
a patch to fix that.
> 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.
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.
Regards,
Diederik
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:[email protected] 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
On Tue, Jan 24, 2023 at 02:32:26PM +0100, Diederik de Haas wrote:
> On Tuesday, 24 January 2023 03:49:02 CET Bagas Sanjaya wrote:
> > On Sun, Jan 22, 2023 at 08:34:43PM +0100, Diederik de Haas wrote:
> > > Signed-off-by: Diederik de Haas <[email protected]>
> >
> > No patch description, really?
>
<some odd rationale to describe why your commit log is empty>
> So I could've added "The full name of the GPL is not GNU Public License, but
> GNU *General* Public License." to/as the explanation body, but I didn't
> consider that to provide extra (needed) info which wasn't clear from the
> Subject and diff.
>
> My only previous patch submission (to the linux kernel) did contain a full
> explanation body: 7074b39d83f5d71fa4f0521b28bd4fb3a22152c1
>
> *) 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.
> 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/
We use SPDX for precise langauges for the license used. Patches like
these and the one you just sent are otherwise not adding more.
> 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).
The only reference we care for is the SPDX one and that work is already done.
As such minor fixes in spelling like yours won't do any good but just
noise at this point. That's exactly why SPDX license tags were
embraced, to make this simple and let us move on with life while having
one simple codified reference to the license so we don't need to deal
with redundant patches fixing grammar on license many times.
As such this changes is not needed.
Luis