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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230510190517.26f11d4a@kernel.org>
Date: Wed, 10 May 2023 19:05:17 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Leon Romanovsky <leon@...nel.org>
Cc: Lukas Wunner <lukas@...ner.de>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 netdev@...r.kernel.org, Philipp Rosenberger <p.rosenberger@...bus.com>, Zhi
 Han <hanzhi09@...il.com>
Subject: Re: [PATCH net-next] net: enc28j60: Use threaded interrupt instead
 of workqueue

On Tue, 9 May 2023 16:56:13 +0300 Leon Romanovsky wrote:
> > > This is part of changelog which doesn't belong to commit message. The
> > > examples which you can find in git log, for such format like you used,
> > > are usually reserved to maintainers when they apply the patch.  
> > 
> > Is that a new rule?  
> 
> No, this rule always existed, just some of the maintainers didn't care
> about it.
> 
> > 
> > Honestly I think it's important to mention changes applied to
> > someone else's patch, if only to let it be known who's to blame
> > for any mistakes.  
> 
> Right, this is why maintainers use this notation when they apply
> patches. In your case, you are submitter, patch is not applied yet
> and all changes can be easily seen through lore web interface.
> 
> > 
> > I'm seeing plenty of recent precedent in the git history where
> > non-committers fixed up patches and made their changes known in
> > this way, e.g.:  
> 
> It doesn't make it correct.
> Documentation/maintainer/modifying-patches.rst

TBH I'm not sure if this is the correct reading of this doc.
I don't see any problem with Lukas using the common notation.
It makes it quite obvious what he changed and the changes are
not invasive enough to warrant a major rewrite of the commit msg.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ