[U-Boot] [PATCH] Fix spelling of "occurred".

[Scott Wood <oss@buserror.net>]

On Mon, 2016-05-02 at 13:26 -0600, Simon Glass wrote:
> Hi Scott,
> 
> On 2 May 2016 at 13:03, Scott Wood <oss@buserror.net> wrote:
> > On Mon, 2016-05-02 at 12:57 -0600, Simon Glass wrote:
> > > Hi Scott,
> > > 
> > > On 1 May 2016 at 17:34, Scott Wood <oss@buserror.net> wrote:
> > > > On Sun, 2016-05-01 at 12:55 -0600, Simon Glass wrote:
> > > > > Hi,
> > > > > 
> > > > > On 30 April 2016 at 20:18, Vagrant Cascadian <vagrant@debian.org>
> > > > > wrote:
> > > > > 
> > > > > Please can you add a commit message?
> > > > 
> > > > I don't understand these "empty/missing commit message" remarks when
> > > > there's a
> > > > one-line changelog (in the subject).  Do you seriously want the same
> > > > line
> > > > repeated twice in the git commit, just so something shows up in the
> > > > body
> > > > of
> > > > the e-mail?  It's one thing if the commit warrants more than a single
> > > > line
> > > > (though it's still not accurate to say that the changelog is
> > > > completely
> > > > absent), but a spelling fix is about as trivial as it gets...
> > > > -Scott
> > > > 
> > > 
> > > It only takes a few seconds to add a commit message and I think it is
> > > good practice.
> > > 
> > > But if you want to allow commits with no message (other than
> > > merge/release tag), then we should document it here:
> > > http://www.denx.de/wiki/U-Boot/Patches
> > 
> > There is a commit message.  It is 'Fix spelling of "occurred"'.
> > 
> > And that wiki link explicitly says, "Put a detailed description after the
> > summary and blank line. If the summary line is sufficient to describe the
> > change, you can omit the blank line and detailed description."
> 
> OK I made a little update to make it more limited:
> 
> "Put a detailed description after the summary and blank line. If the
> summary line is sufficient to describe the change (e.g. it is a
> trivial spelling correction or whitespace update), you can omit the
> blank line and detailed description."
> 
> Does that seem reasonable?

It's an example so it doesn't really limit anything -- if it did, I think
that'd be way too specific.  The criteria should be whether the single line
adequately describes the patch (including justification, etc. if non-obvious).
 If it doesn't, then ask for a more detailed changelog, the same as you would
if it contained more than one line but still didn't adequately describe the
patch.

> We should avoid submitting new drivers and forgetting a commit
> message.

I could see a new driver sometimes reasonably having a one-line commit message
(which is not the same as "forgetting a commit message").  It's a driver for
hardware <foo>.  If there's nothing unusual to be noted about the driver,
known limitations, etc. then what else is there to say?

>  Also some fixes are trivial (e.g. adding 1 to a result) but
> the reason for them needs to be explained.

Yes, but simply mandating text beyond the summary line is likely to get you
stuff like:

foo: Add 1 to result of blah()

Add one to the result of blah().

Signed-off-by: whoever

The problem there is not brevity, it's that important information is missing.

> Sorry if I'm being picky on this. I've spent a *lot* of time over the
> past few years digging into code and finding changes that are not
> self-explanatory. That's why I am keen on people adding comments to
> header files for API functions and struct members

Yes, we could definitely use more API/struct documentation.  I have no problem
with pushing for better changelogs in cases where more information would be
helpful.  But we shouldn't mandate the changelog equivalent of:

	i++; /* add one to i */

>  I think it helps for people to answer the question 'why should this
> code be submitted?' when writing a commit message. For the record. in
> this case, I would have added a message something like 'Occurred is
> spelled incorrectly in a number of places. Fix these up to provide
> consistency'.

OK, but "fix spelling" followed by a diff showing the misspellings conveys the
same information quite clearly.

-Scott