netdev - Re: [PATCHv3 net-next 1/6] sctp: add sctp_info dump api for sctp

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]

Message-ID: <20160418101824.GB14683@orbyte.nwl.cc>
Date:	Mon, 18 Apr 2016 12:18:24 +0200
From:	Phil Sutter <phil@....cc>
To:	David Miller <davem@...emloft.net>
Cc:	lucien.xin@...il.com, netdev@...r.kernel.org,
	linux-sctp@...r.kernel.org, marcelo.leitner@...il.com,
	vyasevich@...il.com, daniel@...earbox.net, eric.dumazet@...il.com
Subject: Re: [PATCHv3 net-next 1/6] sctp: add sctp_info dump api for sctp_diag

On Fri, Apr 15, 2016 at 05:28:58PM -0400, David Miller wrote:
> Feedback was given here not to mix the changelog and the commit message.
> 
> And I want to explicitly state that I totally and _COMPLETELY_ disagree
> with this.
> 
> It is absolutely essential information and belongs in the commit message.
> 
> Adding more information never hurts, so don't do this crap of putting
> things that might be useful to know after the "---", ever.
> 
> Someone in the future might ask "why didn't he implement it like XXX"
> and the changelog can tell him that originally that is what was done
> and feedback was given to do it differently.

I see your point and am well aware the last word on this belongs to you.
Still I would like to explain why I disagree:

In my understanding, the changelog addresses reviewers only, so they
know what to expect or which new chunks to have another look at.  If the
changelog provides valuable information beyond that, I think the mistake
was to not update the commit message accordingly.

Imagine a patchset being rerolled ten times with massive changes in
between - do you really appreciate if the changelog applies to v1 only
and people have to read through nine increments to find out what is
actually being done?

Although I'm exaggerating, one could apply the same logic to the code
changes itself and demand v1 being applied as is with each evolution
separately on top, as otherwise information is lost.

Cheers, Phil
> 
> So Xin thanks for correctly putting the changelog inside of the commit
> message, so that future developers can benefit from this knowledge.