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
