From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] scripts: check cc stable mailing list in commit
Date: Mon, 16 Jan 2017 22:46:09 +0800 [thread overview]
Message-ID: <20170116144609.GE10293@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <4183619.bfC9sCq4mC@xps13>
On Mon, Jan 16, 2017 at 03:26:03PM +0100, Thomas Monjalon wrote:
> > > > Besides, if there is already an explicit way, why should we stick on the
> > > > implicit way?
> > >
> > > Because the explicit way is not 100% proof.
> >
> > Yes, but I think it will be close to "100%" as time moves forward, when all
> > people are really used to add "cc: stable" tag, when there are just few need
> > to be added manually by the kind committers, when people know that the chance
> > your patch will not be in a stable release will be MUCH higher if you don't
> > do that.
> >
> > > I think we still need to check manually to avoid missing too many fixes.
> >
> > I agree. It's un-avoidable, especially in the first stage like where we are
> > now. But my purpose is to create some solid working styles, so that it would
> > be eaiser and convenient for everyone who wants to take such role in future.
> >
> > That said, I will still look the git history, to do some extra manual check.
> > I may still use the script (git-log-fixes.sh) for a while. But the long goal
> > is to get rid of it, because there are so many things you have to check
> > mannually with that.
> >
> > > The other way (that you are advocating) means that we accept to miss
> > > some fixes and it will enforce the community to become better and better to
> > > manage that.
> > > I can agree to your way of thinking. I just want to make it 100% clear to
> > > everyone and read the feedbacks.
> > >
> > > My conclusion: the work of stable maintainer should be simpler and better
> > > automated. If we miss some fixes because of the automated process, it means
> > > we must be better in this process :)
> > > The most reliable source of trust in this automated process should be the
> > > list of patches appearing on the stable mailing list at any time (on first
> > > send or after it has been merged in the mainline).
> >
> > As stated, it's really hard: despite there are many versions, the biggest
> > difficult is commiters like to change the subject a bit. For example, here
> > is one work from myslef :/
> >
> > [PATCH] vhost: Introduce vhost-user's REPLY_ACK feature
> >
> > That's the one you see in the mailing list, and following is what you will
> > see in the git (after my twist):
> >
> > vhost: introduce reply ack feature
>
> OK I understand your long term goal.
Thank you!
> I suggest to move forward by explaining this need in the contribution guide.
Sure. My plan was,
- make a contribution guide
- update the roadmap
The reason I have postoned the two for a while is I have few more thoughts
to refine the stable release a bit, which I will give more details in
another email in days.
--yliu
next prev parent reply other threads:[~2017-01-16 14:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-21 22:43 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 [this message]
2017-01-16 10:38 ` Ferruh Yigit
2017-01-16 10:54 ` Yuanhan Liu
2016-12-01 13:43 ` [dpdk-dev] [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=20170116144609.GE10293@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=thomas.monjalon@6wind.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).