All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>,
	Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH] scripts: check cc stable mailing list in commit
Date: Mon, 16 Jan 2017 10:38:02 +0000	[thread overview]
Message-ID: <8e22bad7-53c6-6809-0604-63d72c01c7ae@intel.com> (raw)
In-Reply-To: <20170116095152.GQ9770@yliu-dev.sh.intel.com>

On 1/16/2017 9:51 AM, Yuanhan Liu wrote:
> On Wed, Nov 30, 2016 at 02:54:14PM +0000, Ferruh Yigit wrote:
>> On 11/21/2016 10:43 PM, Thomas Monjalon wrote:
>>> Add a check for commits fixing a released bug.
>>> Such commits are found thanks to scripts/git-log-fixes.sh.
>>> They must be sent CC: stable@dpdk.org.
>>> In order to avoid forgetting CC, this mail header can be written
>>> in the git commit message.
>>>
>>> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
>>
>> I think this is useful, thanks for the patch.
> 
> Yes, it is. Thanks! (Sorry for late reply; hope it's not too late).
> 
>>> +[ -z "$bad" ] || printf "Should CC: stable@dpdk.org\n$bad\n"
>>
>> This is good for developer, but since "CC: xx" tags removed when patch
>> applied,
> 
> Again, I'd suggest to __not__ remove such tag. Firstly, why bother? And
> I will talk why this tag should be kept, as a stable tree maintainer.
> 
> At the beginning, when people are not used to add "cc: stable" tag, I used
> to pick bug fix commits from master by something like: list all bug fixing
> patches and pick those that appliable to previous release.
> 
> Later, kudos to Thomas, who wrote an handy script (git-log-fixes.sh) to
> do both, it indeeded make my life much easier. But it's still not enough.
> 
> It lists a lot of patches (206 fix patches, while 728 in total: the
> ratio is near 30%):
> 
>     $ devtools/git-log-fixes.sh v16.07..v16.11 | wc -l
>     206
>     
>     $ git rev-list v16.07..v16.11 | wc -l
>     728
> 
> Thus I dropped few of them, manually, resulting to 130 (still looks like
> a big number to me):
> 
>     $ git rev-list v16.07..v16.07.2 | wc -l
>     130
> 
> The policy I would expect is, leave this tag as it is, I then will apply
> all of them to a stable branch: I will no longer do the picking job. Instead,
> I may just need handle those can't apply cleanly and ask the author to
> do backport.

Won't all patches that has CC:stable... also would have Fixes: line?

> 
> It would be do-able now, as I saw a lot of people are getting used to add
> such tag. And even not, I saw those kind committers do that for them.
> 
> Besides, if there is already an explicit way, why should we stick on the
> implicit way?
> 
> 	--yliu
> 
>> this will generate warnings when run against existing history.
>>
>> I don't know what can be done for this.
>>
>> Or should we keep CC: tags in commit log perhaps?
>>
>>>

  parent reply	other threads:[~2017-01-16 10:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-21 22:43 [PATCH] scripts: check cc stable mailing list in commit Thomas Monjalon
2016-11-30 14:54 ` Ferruh Yigit
2016-11-30 15:09   ` Thomas Monjalon
2016-11-30 15:26     ` Bruce Richardson
2016-11-30 15:31       ` Thomas Monjalon
2016-11-30 15:36         ` Bruce Richardson
2017-01-16  9:51   ` Yuanhan Liu
2017-01-16 10:37     ` Thomas Monjalon
2017-01-16 11:19       ` Yuanhan Liu
2017-01-16 14:26         ` Thomas Monjalon
2017-01-16 14:46           ` Yuanhan Liu
2017-01-16 10:38     ` Ferruh Yigit [this message]
2017-01-16 10:54       ` Yuanhan Liu
2016-12-01 13:43 ` [PATCH v2] " Thomas Monjalon
2016-12-01 15:00   ` Ferruh Yigit
2016-12-01 15:03     ` Thomas Monjalon

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=8e22bad7-53c6-6809-0604-63d72c01c7ae@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=dev@dpdk.org \
    --cc=thomas.monjalon@6wind.com \
    --cc=yuanhan.liu@linux.intel.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.