[Ksummit-discuss] [CORE TOPIC] stable workflow
Takashi Iwai
tiwai at suse.de
Thu Aug 4 15:32:48 UTC 2016
On Thu, 04 Aug 2016 15:33:55 +0200,
Steven Rostedt wrote:
>
> On Thu, 4 Aug 2016 10:20:18 +0200
> Greg KH <greg at kroah.com> wrote:
>
> > On Wed, Aug 03, 2016 at 09:23:32PM -0400, Steven Rostedt wrote:
> > > On Wed, 03 Aug 2016 10:04:55 -0400
> > > James Bottomley <James.Bottomley at HansenPartnership.com> wrote:
> > >
> > >
> > > > OK, so how about you only apply stable patches with a cc stable and a
> > > > fixes tag?
> > >
> > > While reading this thread, I thought about replying and suggesting
> > > exactly this. But you did it before I could.
> > >
> > > I try to make it a habit to find the commit that a fix is for, and add
> > > that as a Fixes tag and even add a # v<stable-version>+ to the Cc tag.
> > >
> > > Maybe we ask that all cc stable commits have this, otherwise it should
> > > only be applied to the previous stable and nothing earlier.
> >
> > No, again, that would put more burden on the maintainer and developer
> > than I want to "enforce". I don't even want to do that extra work for
> > the trees I maintain, I just couldn't scale that way.
>
> Note, this isn't just good practice for sending patches to stable, it's
> general good practice maintaining code. It gives a nice history of a
> change. If you look at the change log of code that one might see that
> looks "interesting" it may be very educational to see that it was done
> as a fix for something else. And a new developer may understand why
> code was added in the first place.
>
> I don't buy this as burden on a maintainer. This should be part of the
> maintenance procedure, regardless of sending to stable or not. Yes it
> does take extra time, but I don't think that time is wasted.
Agreed that it's a good practice. But what if a fix isn't a
regression fix? Many stable patches are trivial ones like PCI ID
additions.
We may point any of the commit to the corresponding code, but does it
make sense at all?
thanks,
Takashi
More information about the Ksummit-discuss
mailing list