All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Elfring <Markus.Elfring@web.de>
To: Wang YanQing <udknight@gmail.com>, kernel-janitors@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Andy Whitcroft <apw@canonical.com>, Joe Perches <joe@perches.com>,
	Matteo Croce <mcroce@redhat.com>
Subject: Re: [v3] checkpatch: add dedicated checker for 'Fixes:' tag
Date: Wed, 29 Apr 2020 17:18:52 +0200	[thread overview]
Message-ID: <f1234e16-eca2-e2af-c5a6-92f47fcbd98d@web.de> (raw)
In-Reply-To: <20200428161831.GB30042@udknight>

>> * Do you try to extend the existing software analysis approach “GIT_COMMIT_ID”?
>>
>> * Would you like to avoid the development of duplicate Perl code?
>
> Fixes: lines don't need to have a "commit" prefix before the commit id, the description
> in normal commit id could across multiple lines, and we don't need to consider the
> $commit_log_possible_stack_dump for 'Fixes:' tag line.

It can be helpful to know such differences.


> I mean it will make the GIT_COMMIT_ID code become harder to read and maintain.

This view depends on some factors.

* How many data processing can be shared for your software extension?

* Do you get any further development ideas from a previous suggestion
  by Joe Perches according to the discussion topic “linux-next:
  Fixes tag needs some work in the tip tree”?
  https://lkml.org/lkml/2019/1/17/966
  https://lore.kernel.org/lkml/40bfc40958fca6e2cc9b86101153aa0715fac4f7.camel@perches.com/

Regards,
Markus

WARNING: multiple messages have this Message-ID (diff)
From: Markus Elfring <Markus.Elfring@web.de>
To: Wang YanQing <udknight@gmail.com>, kernel-janitors@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Andy Whitcroft <apw@canonical.com>, Joe Perches <joe@perches.com>,
	Matteo Croce <mcroce@redhat.com>
Subject: Re: [v3] checkpatch: add dedicated checker for 'Fixes:' tag
Date: Wed, 29 Apr 2020 15:18:52 +0000	[thread overview]
Message-ID: <f1234e16-eca2-e2af-c5a6-92f47fcbd98d@web.de> (raw)
In-Reply-To: <20200428161831.GB30042@udknight>

>> * Do you try to extend the existing software analysis approach “GIT_COMMIT_ID”?
>>
>> * Would you like to avoid the development of duplicate Perl code?
>
> Fixes: lines don't need to have a "commit" prefix before the commit id, the description
> in normal commit id could across multiple lines, and we don't need to consider the
> $commit_log_possible_stack_dump for 'Fixes:' tag line.

It can be helpful to know such differences.


> I mean it will make the GIT_COMMIT_ID code become harder to read and maintain.

This view depends on some factors.

* How many data processing can be shared for your software extension?

* Do you get any further development ideas from a previous suggestion
  by Joe Perches according to the discussion topic “linux-next:
  Fixes tag needs some work in the tip tree”?
  https://lkml.org/lkml/2019/1/17/966
  https://lore.kernel.org/lkml/40bfc40958fca6e2cc9b86101153aa0715fac4f7.camel@perches.com/

Regards,
Markus

  reply	other threads:[~2020-04-29 15:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28  2:02 [PATCH v3] checkpatch: add dedicated checker for 'Fixes:' tag Wang YanQing
2020-04-28  2:02 ` Wang YanQing
2020-04-28  6:21 ` Markus Elfring
2020-04-28  6:21   ` Markus Elfring
2020-04-28 14:06   ` Wang YanQing
2020-04-28 14:06     ` Wang YanQing
2020-04-28 14:54     ` [v3] " Markus Elfring
2020-04-28 14:54       ` Markus Elfring
2020-04-28 10:52 ` [PATCH v3] " Markus Elfring
2020-04-28 10:52   ` Markus Elfring
2020-04-28 16:18   ` Wang YanQing
2020-04-28 16:18     ` Wang YanQing
2020-04-29 15:18     ` Markus Elfring [this message]
2020-04-29 15:18       ` [v3] " Markus Elfring
2020-04-28 16:10 ` [PATCH v3] " Joe Perches
2020-04-28 16:10   ` Joe Perches
2020-04-28 23:17   ` Joe Perches
2020-04-28 23:17     ` Joe Perches
2020-04-29  6:45     ` [v3] " Markus Elfring
2020-04-29  6:45       ` Markus Elfring

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=f1234e16-eca2-e2af-c5a6-92f47fcbd98d@web.de \
    --to=markus.elfring@web.de \
    --cc=alexei.starovoitov@gmail.com \
    --cc=apw@canonical.com \
    --cc=joe@perches.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcroce@redhat.com \
    --cc=udknight@gmail.com \
    /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.