Re: [PATCH] scripts: check cc stable mailing list in commit

[Yuanhan Liu <yuanhan.liu@linux.intel.com>]

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