Re: [PATCH v4 0/3] use wincap in format_proc_cpuinfo for user_shstk

[Brian Inglis <Brian.Inglis@Shaw.ca>]

On 2023-06-21 02:22, Corinna Vinschen wrote:
> On Jun 20 22:50, Brian Inglis wrote:
>> On 2023-06-20 02:22, Corinna Vinschen wrote:
>>> Never mind, I fixed the remaining problems.  Thanks for the patch,
>>> I pushed it with slight modifications to the commit messages.
>>>
>>> I'm a bit puzzled if my original mail
>>> https://cygwin.com/pipermail/cygwin-patches/2023q2/012280.html
>>> was really that unclear.  Reiterating for the records:
>>>
>>> - Commit messages should really try to explain why the patch is made and
>>>     what it's good for. In case of fixing a bug, the bug should be explained
>>>     and, ideally, explain why the patch is the better solution.
>>>
>>> - If a patch fixes an older bug, it should say so and point out the
>>>     commit which introduced the bug using the Fixes: tag.  The format
>>>     is
>>>       Fixes: <12-digit-SHA1> ("<commit headline>")
>>>
>>>     The parens and quoting chars are part of the format.
>>>
>>> - Every patch should contain a Signed-off-by: to indicate that
>>>     you did the patch by yourself.  That's easily automated by
>>>     using `git commit -s'.
>>>
>>> - Other Tags like "Reported-by:" or "Tested-by:" are nice to have,
>>>     but not essential.
>>
>>>> - For obvious reasons, the message text in your cover message won't make
>>>>    it into the git repo.  However, the commit messages in git should
>>>>    reflect why the change was made, so a future interested reader has
>>>>    a chance to understand why a change was made.
>>
>> Not obvious to me unfortunately!
> 
> No worries, we're all learning while we're going along.
> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst
> 
> This is pretty well written, and it very nicely explains how to write
> commit messages and use tagging.
> 
> Writing useful commit messages helps other people a lot to understand
> why a patch was made, especially in tricky error cases (locking issues
> are hard to follow, a good explanation is key).
> 
> If you ask me, there's no such thing as a too long commit message.
> 
> We're a small group so we're not supposed to follow the above document
> to the core.  However, things like "Fixes:" are really great, because
> they connect a patch with a history of other patches and allow an aha
> effect when checking on the referenced older patch.  I can honestely
> tell you that it already helped me a lot when working on the Linux
> kernel.  That's why I'd like to make this standard for our small project
> here, too.
> 
> And one of the core expressions used in this doc is this:
>    Don't get discouraged - or impatient
> :)

Cheers - never discouraged - a bit impatient because often frustrated - 
sometimes confused - like Alice and the White Knight's song "Haddocks' Eyes" - 
finding that the /footers/ are sometimes called /headers/ and other times /tags/ 
but actually named *trailers* finally gave more useful results where /fixes/ did 
not! ;^>

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry