From: Greg KH <greg@kroah.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
Sasha Levin <sasha.levin@oracle.com>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Issues with stable process
Date: Tue, 1 Sep 2015 13:52:35 -0700 [thread overview]
Message-ID: <20150901205235.GA7344@kroah.com> (raw)
In-Reply-To: <874mje5y13.fsf@intel.com>
On Tue, Sep 01, 2015 at 11:44:40AM +0300, Jani Nikula wrote:
> On Tue, 14 Jul 2015, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > On Mon, 2015-07-13 at 20:28 -0600, Jonathan Corbet wrote:
> >> On Mon, 13 Jul 2015 21:02:26 -0400
> >> Steven Rostedt <rostedt@goodmis.org> wrote:
> >>
> >> > Yes, it's great if we can catch things in -next. But I don't believe
> >> > that patches that fix bugs found in Linus's tree should sit in next
> >> > before going into Linus's tree, because those patches are basically
> >> > fixing stuff that was already in next and wasn't discovered until it
> >> > hit Linus's tree. Which is why I say it's a waste of time to put it in
> >> > next before sending straight to Linus.
> >>
> >> That, of course, assumes that these fixes don't introduce *other* bugs
> >> that might just be caught in -next...
> >>
> >> In general, though, I think a lot of people see -next as -rc1 without the
> >> quality control; it's volatile and scary. So it's not surprising that it
> >> doesn't get a lot of real-world testing. And, as long as that's the case,
> >> there's going to be a lot of bugs that are never caught in -next.
> >
> > Yes, I'm with this. Instantly into Linus' tree means we get a lot of
> > bug introducing fixes which we then have to sort out. One of the
> > complaints the stable tree maintainers and the distros are making is
> > that it's hard to track the set of patches required for a fix that was
> > first done wrongly.
>
> Digging up an old thread, sorry...
>
> I think one of the issues with the stable process is that when we add
> stable tags (or Fixes: references) they are cast in stone in the commit
> history. We can fix the code and everyone sees the current version, but
> when you look at a commit intended for stable, it's not always as
> trivial to figure out whether that was a good idea in hindsight.
>
> When I sort out the drm/i915 fixes for current development kernels (or
> -next) I often spend quite a bit of time doing git log/blame archeology
> figuring out if it's a regression fix and what the regressing commit
> was, etc. I've thought about scripting the git history to add git notes
> to the commits that are referred to by later commits, as this would be
> helpful in figuring out if there are *other* commits fixing issues in
> the same regressing one. Alas I've never found the time.
>
> I'm wondering if people would think it worthwhile to have a
> collaborative effort of annotating commits using git notes, both
> automatically and manually. The manual annotations might be things like,
> "Cc: stable", "whoops, this was a bad idea for stable", or "this also
> needs commit foo in stable". Of course, with more structure, but you get
> the idea.
git notes are a pain to propagate around, so while I like the idea of
this, I don't know how well the proposed solution would work.
thanks,
greg k-h
next prev parent reply other threads:[~2015-09-01 20:52 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-11 16:12 [Ksummit-discuss] [CORE TOPIC] Issues with stable process Sasha Levin
2015-07-12 10:02 ` Geert Uytterhoeven
2015-07-12 13:32 ` Sasha Levin
2015-07-13 0:52 ` NeilBrown
2015-07-13 3:32 ` Andy Lutomirski
2015-07-13 4:27 ` Sasha Levin
2015-07-13 5:10 ` NeilBrown
2015-07-13 22:55 ` Rafael J. Wysocki
2015-07-13 18:21 ` Steven Rostedt
2015-07-13 18:51 ` Mark Brown
2015-07-15 14:52 ` Olof Johansson
2015-07-15 15:59 ` Guenter Roeck
2015-07-15 16:03 ` Greg KH
2015-07-15 16:15 ` Sasha Levin
2015-07-15 16:40 ` Greg KH
2015-07-15 19:34 ` Josh Boyer
2015-07-15 21:21 ` Sasha Levin
2015-07-15 22:34 ` Greg KH
2015-07-15 22:40 ` Sasha Levin
2015-07-16 3:36 ` Greg KH
2015-07-17 0:52 ` Rafael J. Wysocki
2015-07-16 9:06 ` Zefan Li
2015-07-16 18:14 ` Olof Johansson
2015-07-14 0:42 ` Sasha Levin
2015-07-14 1:02 ` Steven Rostedt
2015-07-14 2:00 ` Sasha Levin
2015-07-14 2:28 ` Jonathan Corbet
2015-07-14 3:48 ` Stephen Rothwell
2015-07-14 7:14 ` Geert Uytterhoeven
2015-07-14 11:03 ` James Bottomley
2015-07-14 13:29 ` Steven Rostedt
2015-07-14 20:17 ` James Bottomley
2015-07-14 20:45 ` Mark Brown
2015-07-14 22:12 ` Steven Rostedt
2015-07-14 22:36 ` Andy Lutomirski
2015-09-01 8:44 ` Jani Nikula
2015-09-01 20:52 ` Greg KH [this message]
2015-09-01 21:00 ` Sasha Levin
2015-09-01 21:08 ` Jiri Kosina
2015-09-01 22:47 ` Sasha Levin
2015-09-02 10:10 ` Luis Henriques
2015-07-16 0:53 ` Rafael J. Wysocki
2015-07-16 11:50 ` Mark Brown
2015-07-14 3:42 ` Stephen Rothwell
2015-07-14 7:03 ` Geert Uytterhoeven
2015-07-14 10:46 ` Mark Brown
2015-07-14 13:57 ` Sasha Levin
2015-07-14 15:25 ` Mark Brown
2015-07-14 15:32 ` Sasha Levin
2015-07-14 15:38 ` Steven Rostedt
2015-07-14 15:53 ` Sasha Levin
2015-07-14 16:02 ` Steven Rostedt
2015-07-14 19:30 ` Sasha Levin
2015-07-14 19:38 ` Steven Rostedt
2015-07-15 1:49 ` NeilBrown
2015-07-15 2:09 ` Sasha Levin
2015-07-15 2:28 ` NeilBrown
2015-07-15 10:13 ` James Bottomley
2015-07-15 23:24 ` NeilBrown
2015-07-16 1:05 ` Andy Lutomirski
2015-07-16 1:43 ` Linus Torvalds
2015-07-16 1:25 ` Steven Rostedt
2015-07-16 9:19 ` James Bottomley
2015-07-16 12:33 ` Jonathan Cameron
2015-08-03 8:32 ` Fengguang Wu
2015-07-14 15:56 ` Mark Brown
2015-07-14 19:01 ` Sasha Levin
2015-07-14 19:18 ` Geert Uytterhoeven
2015-07-14 19:31 ` Sasha Levin
2015-07-15 9:26 ` Jan Kara
2015-07-16 12:53 ` Mark Brown
2015-07-13 9:22 ` Jan Kara
2015-07-13 20:51 ` Greg KH
2015-07-14 0:51 ` Sasha Levin
2015-07-14 2:46 ` NeilBrown
2015-07-15 19:41 ` Steven Rostedt
2015-07-15 20:14 ` James Bottomley
2015-07-12 15:01 ` Masami Hiramatsu
2015-07-13 10:15 ` Zefan Li
2015-07-13 16:12 ` Sasha Levin
2015-07-14 10:08 ` Zefan Li
2015-07-14 14:00 ` Sasha Levin
2015-07-15 0:01 ` Greg Kroah-Hartman
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=20150901205235.GA7344@kroah.com \
--to=greg@kroah.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=jani.nikula@intel.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=sasha.levin@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.