linux-kernel - Re: [PATCH] Documentation/livepatch: Update terminology in livepatch

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: Thu, 11 Jan 2024 16:17:50 +0100
From: Petr Mladek <pmladek@...e.com>
To: Marcos Paulo de Souza <mpdesouza@...e.com>
Cc: Jonathan Corbet <corbet@....net>, Attreyee M <tintinm2017@...il.com>,
	Bagas Sanjaya <bagasdotme@...il.com>, jpoimboe@...nel.org,
	jikos@...nel.org, mbenes@...e.cz, joe.lawrence@...hat.com,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	live-patching@...r.kernel.org
Subject: Re: [PATCH] Documentation/livepatch: Update terminology in livepatch

On Wed 2024-01-10 15:51:40, Marcos Paulo de Souza wrote:
> On Wed, 2024-01-10 at 11:15 -0700, Jonathan Corbet wrote:
> > Attreyee M <tintinm2017@...il.com> writes:
> > 
> > > Hello maintainers, 
> > > 
> > > I wanted to ask if this patch of mine is accepted as of now. 
> > 
> > You never responded to the question that is still quoted in your
> > (unfortunately top-posted) email:
> > 
> > > So this is a classic example of saying what you have done, but not
> > > why.
> > > What makes this a change that we want?
> > 
> > So no, not accepted.  Even with a proper changelog, though, I'm not
> > sure
> > I see the value in that particular change.
> 
> >From time to time I see people complaining about the lack of new people
> coming to kernel development,

IMHO, it is much worse on the maintainers' side. There is a lack
of maintainers. And I believe that most of them have hard times
to manage the load. They should provide hints. But we could
not expect that they would do the work.

> and that Documentation would be a good
> start for some of them to learn how to send patches by email (which by
> itself is difficult...).

Attreyee, please read Documentation/process/submitting-patches.rst
before you send another version.

Also please run scripts/checkpatch.pl before you send the patches.

> As Documentation patches aren't backported, why not accept this patch?
> 
> Jon, I understand your reasoning, but I agree with Attreyee here. The
> term "acquire" fits better when in conjunction with "released" than
> "get".
> 
> Can you show an example of a good commit message to Attreyee so he can
> adjust and resend? I'm sure the next time he'll consider remember the
> suggestion given and the next patch will have a better commit message.

I suggest that Attreyee makes another attempt himself.

John explained what was the problem. Attreyee could get inspiration from
the git history. Anyway, the commit message simply should explain why
"acquire" is better than "get".

Best Regards,
Petr