All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Andy Green <andy@warmcat.com>
Cc: dev@dpdk.org, Stephen Hemminger <stephen@networkplumber.org>,
	Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [PATCH v3 00/40] Fix build on gcc8 and various bugs
Date: Sun, 13 May 2018 15:58:53 +0200	[thread overview]
Message-ID: <1962043.pv7O6beyaF@xps> (raw)
In-Reply-To: <cc0111a3-b60c-a59a-40fe-187e78f8f8f1@warmcat.com>

Hi,

11/05/2018 02:29, Andy Green:
> 
> On 05/10/2018 11:01 PM, Stephen Hemminger wrote:
> > On Thu, 10 May 2018 20:13:31 +0800
> > Andy Green <andy@warmcat.com> wrote:
> > 
> >> I appreciate the reply.
> >>
> >> But why bother having a subject line at all if it is going to be
> >> mechanically enforced that nothing in it is allowed to be "useful"?
> >> That really doesn't make sense does it.
> > 
> > It was done because there were lots of clueless patches showing
> > up on the driver development list which had useless subject
> > lines.

Yes, the title should help to quickly identify the scope of the commits.
Usually, giving variable names, function names, etc are not very useful.
It is very common that some developers say "fixing function X" instead
of describing the fixed behaviour: "fixing feature Y".

> The "cure" is worse than the disease...

It is a tool showing some warnings.
We must be smart when using this tool (as any other tools)
and consider that some warnings are false positive.

>   - I can mention, eg, that something changed to an int.  But a size_t 
> or my_type_t?  I am not allowed to mention it even if that is the whole 
> reason for the patch.

Of course you can use size_t in the title if it is relevant.
Sometimes, changing a type is fixing a feature, so better to name the feature.

>   - I can mention most libc apis, but not those that happen to have an 
> underscore, eg, timerfd_create(), even if that was the focus of the patch.
> 
>   - Any kind of manifest constant like MY_CONSTANT: illegal to mention, 
> even if the patch's job is change MY_CONSTANT to, say, 5.  What should I 
> entitle that patch?  "lib: change something to 5"?  "lib: change 
> MY.CONSTANT to 5"?
> 
>   - I can mention most filenames or paths, eg, down /proc, or myfile.c. 
> But not if the filepath happens to contain an underscore.  Even if the 
> effect of the patch is to migrate stuff from myfile.c to my_files/
> 
> The results are arbitrary... please consider removing this now it has 
> been in place a while and made its original point.

I hope you got my point that the title should be a high level description
of the scope or goal of the patch.
The details are inside the commit log.
But using underscore is accepted in the title if relevant.

Every strong rules are stupids, that's why we have only guidelines
and we are flexible.

  parent reply	other threads:[~2018-05-13 13:58 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-10  2:46 [PATCH v3 00/40] Fix build on gcc8 and various bugs Andy Green
2018-05-10  2:46 ` [PATCH v3 01/40] drivers/bus/pci: fix strncpy dangerous code Andy Green
2018-05-10 12:55   ` De Lara Guarch, Pablo
2018-05-10  2:46 ` [PATCH v3 02/40] drivers/bus/dpaa: fix inconsistent struct alignment Andy Green
2018-05-10  2:46 ` [PATCH v3 03/40] drivers/net/axgbe: fix broken eeprom string comp Andy Green
2018-05-10  2:46 ` [PATCH v3 04/40] drivers/net/nfp/nfpcore: fix strncpy misuse Andy Green
2018-05-10  2:46 ` [PATCH v3 05/40] drivers/net/nfp/nfpcore: fix off-by-one and no NUL on strncpy use Andy Green
2018-05-10  2:46 ` [PATCH v3 06/40] drivers/net/nfp: don't memcpy out of source range Andy Green
2018-05-10  2:46 ` [PATCH v3 07/40] drivers/net/nfp: fix buffer overflow in fw_name Andy Green
2018-05-10  2:46 ` [PATCH v3 08/40] drivers/net/qede: fix strncpy constant and NUL Andy Green
2018-05-10  2:47 ` [PATCH v3 09/40] drivers/net/qede: fix broken strncpy Andy Green
2018-05-10  2:47 ` [PATCH v3 10/40] drivers/net/sfc: fix strncpy length Andy Green
2018-05-10  2:47 ` [PATCH v3 11/40] drivers/net/sfc: fix strncpy size and NUL Andy Green
2018-05-10  2:47 ` [PATCH v3 12/40] drivers/net/vdev: readlink inputs cannot be aliased Andy Green
2018-05-10  2:47 ` [PATCH v3 13/40] drivers/net/vdev: fix 3 x strncpy misuse Andy Green
2018-05-10  2:47 ` [PATCH v3 14/40] app/test-pmd: can't find include Andy Green
2018-05-10 13:50   ` De Lara Guarch, Pablo
2018-05-10  2:47 ` [PATCH v3 15/40] app/proc-info: fix sprintf overrun bug Andy Green
2018-05-10  2:47 ` [PATCH v3 16/40] app/test-bbdev: test-bbdev: strcpy ok for allocated string Andy Green
2018-05-10  2:47 ` [PATCH v3 17/40] app/test-bbdev: " Andy Green
2018-05-10  2:47 ` [PATCH v3 18/40] rte_common.h: cast gcc builtin result to avoid complaints Andy Green
2018-05-10  2:47 ` [PATCH v3 19/40] rte_memcpy.h: explicit tmp cast Andy Green
2018-05-10  2:47 ` [PATCH v3 20/40] lib/librte_eal/common/include/rte_lcore.h: explicit cast for signed change Andy Green
2018-05-10  2:48 ` [PATCH v3 21/40] /lib/librte_eal/common/include/rte_random.h: stage cast from uint64_t to long Andy Green
2018-05-10  2:48 ` [PATCH v3 22/40] rte_spinlock.h: stack declarations before code Andy Green
2018-05-10  2:48 ` [PATCH v3 23/40] rte_ring_generic.h: " Andy Green
2018-05-10  2:48 ` [PATCH v3 24/40] rte_ring.h: remove signed type flipflopping Andy Green
2018-05-10  2:48 ` [PATCH v3 25/40] rte_dev.h: stack declaration at top of own basic block Andy Green
2018-05-10  2:48 ` [PATCH v3 26/40] rte_mbuf.h: avoid truncation warnings from inadvertant int16_t to int promotion Andy Green
2018-05-10  2:48 ` [PATCH v3 27/40] rte_mbuf.h: explicit casts for flipping between int16_t and uint16_t Andy Green
2018-05-10  2:48 ` [PATCH v3 28/40] rte_mbuf.h: make sure RTE_MIN compares same types Andy Green
2018-05-10  2:48 ` [PATCH v3 29/40] rte_mbuf.h: explicit cast restricting ptrdiff to uint16_t Andy Green
2018-05-10  2:48 ` [PATCH v3 30/40] rte_mbuf.h: explicit cast for size_t to uint32_t Andy Green
2018-05-10  2:48 ` [PATCH v3 31/40] rte_mbuf.h: explicit casts to uint16_t to avoid truncation warnings Andy Green
2018-05-10  2:49 ` [PATCH v3 32/40] rte_byteorder.h: explicit cast for return promotion Andy Green
2018-05-10  2:49 ` [PATCH v3 33/40] rte_ether.h: explicit cast avoiding truncation warning Andy Green
2018-05-10  2:49 ` [PATCH v3 34/40] rte_ether.h: stack vars declared at top of function Andy Green
2018-05-10  2:49 ` [PATCH v3 35/40] rte_ethdev.h: fix sign and scope of temp var Andy Green
2018-05-10  2:49 ` [PATCH v3 36/40] rte_ethdev.h: explicit cast for return type Andy Green
2018-05-10 19:18   ` Stephen Hemminger
2018-05-10 23:48     ` Andy Green
2018-05-10  2:49 ` [PATCH v3 37/40] rte_ethdev.h: explicit cast for truncation Andy Green
2018-05-10  2:49 ` [PATCH v3 38/40] rte_hash_crc.h: stack vars declared at top of function Andy Green
2018-05-10  2:49 ` [PATCH v3 39/40] rte_hash_crc.h: explicit casts for truncation Andy Green
2018-05-10  2:49 ` [PATCH v3 40/40] rte_string_fns.h: explicit cast for int return to size_t Andy Green
2018-05-10 19:17   ` Stephen Hemminger
2018-05-11  0:13     ` Andy Green
2018-05-10  6:12 ` [PATCH v3 00/40] Fix build on gcc8 and various bugs Jerin Jacob
2018-05-10  7:11   ` Andy Green
2018-05-10  9:19     ` Jerin Jacob
2018-05-10  6:17 ` Jerin Jacob
2018-05-10  6:46   ` Andy Green
2018-05-10  9:11     ` Jerin Jacob
2018-05-10 11:44       ` Andy Green
2018-05-10 11:58         ` Jerin Jacob
2018-05-10 12:13           ` Andy Green
2018-05-10 15:01             ` Stephen Hemminger
2018-05-11  0:29               ` Andy Green
2018-05-11  1:37                 ` Andy Green
2018-05-13 13:58                 ` Thomas Monjalon [this message]
2018-05-10  9:52 ` De Lara Guarch, Pablo
2018-05-10 11:57   ` Andy Green
2018-05-10 10:21 ` Luca Boccassi
2018-05-10 12:23   ` Andy Green
2018-05-10 12:35     ` Luca Boccassi
2018-05-10 13:36       ` Bruce Richardson
2018-05-10 13:49         ` Luca Boccassi
2018-05-10 13:53           ` Andy Green
2018-05-10 14:20             ` Andy Green
2018-05-10 13:59         ` Andy Green

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1962043.pv7O6beyaF@xps \
    --to=thomas@monjalon.net \
    --cc=andy@warmcat.com \
    --cc=dev@dpdk.org \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.