Re: [Ksummit-discuss] [CORE TOPIC] stable issues

[Jason Cooper <jason@lakedaemon.net>]

On Sun, May 04, 2014 at 08:47:06PM -0700, Guenter Roeck wrote:
> This may be seen as somewhat strong definition of the term "severe",
> but in my work environment the attitude is to never update the kernel under
> any circumstances. Or, in other words, it is quite hostile to someone who
> advocates following upstream kernel releases. Each new bug, as minor as it
> may be in a practical sense, is seen as argument (or ammunition) against
> kernel updates. Note that this specifically includes performance regressions,
> as minor as they may be. Given that, I would love to see Fengguang's
> performance tests run on stable releases, simply because that would give me
> confidence (and proof) that no performance regressions were introduced.

Along this line, I keep coming back to an idea that I really need to
implement.  Say your shop is running v3.12.3, and you'd like to migrate
to v3.12.7 because of a bugfix for your subsystem.

I imagine it would make the argument easier if you could quantify the
changes from v3.12.3 to v3.12.7 relevant to your kernel config.  eg:

$ git diff v3.12.3..v3.12.7 | ./scripts/diff-filter mydefconfig

(no, diff-filter doesn't exist, yet)

I could also see using ./scripts/objdiff for this as well.  Anything
that would help the engineer quantify the differences between the two
releases so he could ask the question, "Show me *which* change you're
uncomfortable with."

That's a much better position to be in than, "I swear, the -stable
process is legit.  You can trust a bunch of people you've never met who
won't suffer any repercussions if our product fails."

This assumes a fairly minimal config, of course.  ;-)

thx,

Jason.