ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] stable kernel process	automation and improvement
Date: Fri, 05 Jul 2019 16:13:35 +0200	[thread overview]
Message-ID: <s5hwogwy3g0.wl-tiwai@suse.de> (raw)
In-Reply-To: <87lfxc1ta4.fsf@concordia.ellerman.id.au>

On Fri, 05 Jul 2019 15:54:11 +0200,
Michael Ellerman wrote:
> 
> Sasha Levin <sashal@kernel.org> writes:
> > Hi folks,
> >
> > If there is interest, I'd like to go over the (minor) changes that went
> > into the -stable kernel process since last year's MS, the various
> > automations we now have, and how we have addressed some of the pain
> > points that came up last year. I'd also love to hear from folks about
> > the issues they're seeing with the process, and if there's anything we
> > can do to make it better.
> >
> > Some of the concerns that were raised during last year's MS (both in the
> > group session as well as in the hallway track) which we've tried to
> > address are:
> >
> >  - Commits missing because authors did not respond to Greg's "FAILED:"
> >    mails.
> >  - Concerns about how well -stable kernels are tested.
> >  - "Fixes for fixes" end up being missed.
> >  - Saner AUTOSEL process.
> >  - Tracking of dropped commits.
> 
> Yeah definitely interested in this.
> 
> Especially the tracking part. I have been trying to keep track of
> powerpc commits that need backporting, but haven't really come up with a
> good system. So would be interested in what you and/or others are doing.
> 
> Something I've been experimenting with is using git notes to mark
> commits that have been fixed by a subsequent commit. This gives you a
> two way link between the fix and the fixed commit, and you can get the
> notes to show up in git log, like:
> 
>   commit 1846193b178dcc58435fdc57352db7b74826ef37
>   Author: Michael Ellerman <mpe@ellerman.id.au>
>   Date:   Thu Jul 7 22:54:29 2016 +1000
>   
>       powerpc/xmon: Dump ISA 2.06 SPRs
>       
>       Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>   
>   Notes (fixed):
>       Fixed-by: c47a94031e81 ("powerpc/xmon: Fix display of SPRs")
> 
> 
> I'd like to extend this to the stable trees, so you could have output
> something like:
> 
>   commit 1846193b178dcc58435fdc57352db7b74826ef37
>   Author: Michael Ellerman <mpe@ellerman.id.au>
>   Date:   Thu Jul 7 22:54:29 2016 +1000
>   
>       powerpc/xmon: Dump ISA 2.06 SPRs
>       
>       Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>   
>   Notes (fixed):
>       Fixed-by: c47a94031e81 ("powerpc/xmon: Fix display of SPRs")
>         v4.9.y: deadbeef0000 ("powerpc/xmon: Fix display of SPRs")
>        v4.10.y: not found
> 
> 
> Git notes are also just blobs, so in theory the processing to generate
> those notes could be done once and pushed to a repo where everyone could
> pull them.

Yes, I'd love to have (and share) this kind of reverse mapping
information.  But somehow using git-notes for such a purpose wasn't
accepted widely.  IIRC, Linus mentioned that git-notes is a hack, and
indeed it is.  But if the entries aren't too big, it would work well
enough, I guess.  Once when the size matters, we can reconsider to
switch to a better infrastructure...

FWIW, SUSE tracks the possible upstream fixes by parsing Fixes tag
regularly, so it's proven to be useful.


thanks,

Takashi

  reply	other threads:[~2019-07-05 14:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-03  1:35 Sasha Levin
2019-07-03 14:57 ` Laura Abbott
2019-07-05 13:54 ` Michael Ellerman
2019-07-05 14:13   ` Takashi Iwai [this message]
2019-07-05 16:17     ` Greg KH
2019-07-05 16:52     ` Sasha Levin
2019-07-05 16:41 ` Mark Brown
2019-07-05 20:12   ` Sasha Levin
2019-07-06  0:32     ` Mark Brown
2019-07-08 11:02       ` Sasha Levin
2019-07-08 11:35         ` Jiri Kosina
2019-07-08 12:34           ` Greg KH
2019-07-08 17:56           ` Sasha Levin
2019-07-08 12:37         ` Mark Brown
2019-07-08 14:05           ` Guenter Roeck
2019-07-08 14:33             ` Takashi Iwai
2019-07-08 15:10               ` Greg KH
2019-07-08 15:18                 ` Takashi Iwai
2019-07-08 18:08                 ` Sasha Levin
2019-07-08 21:31                 ` Jiri Kosina
2019-07-09 15:44                   ` Rafael J. Wysocki
2019-07-09 21:05                     ` Takashi Iwai
2019-07-09 15:21                 ` Laura Abbott
2019-07-08 14:50             ` Mark Brown
2019-07-08 15:06               ` Greg KH
2019-07-08 15:27                 ` Mark Brown
2019-07-08 18:01           ` Sasha Levin

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=s5hwogwy3g0.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=mpe@ellerman.id.au \
    /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