Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Sat, Jul 13, 2013 at 08:51:28PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jul 13, 2013 at 10:22:19PM -0400, Theodore Ts'o wrote:
> > On Sat, Jul 13, 2013 at 11:27:17AM -0700, Greg Kroah-Hartman wrote:
> > > Ugh, the conversation has degenerated now into parsing the meaning of
> > > specific words.  This is why lawyers have created whole vocabularies
> > > that are not used by "normal" people.  There's a very good reason why
> > > I'm not a lawyer, and this is one of them...
> > > 
> > > If I change the word "critical" to "real", would that make everyone
> > > happy here?
> > > 
> > > It comes down to the simple fact that for stable kernels I _want_ to
> > > take bugfixes that any user would hit.  In other words, something that a
> > > distro kernel would take.
> > 
> > Yes, but ***Linus*** has said he only wants critical fixes in his tree
> > after -rc4.  It seems pretty clear that what he wants post -rc4 and
> > what you want in the stable tree are different.
> > 
> > You can change the stable_kernel_tree to be "real" bugs, but if Linus
> > is still using "critical" as the standard for mainline post-rc4, then
> > those of us who are maintainers are stuck between a rock and a hard
> > place.
> 
> You are confusing the words "real" and "critical" perhaps.  I, and other

A typical classification of bugs might be
	critical: mission critical, no workaround, must be fixed prior to
		customer release
	severe (high): related to core functionality, must fix, but not
		necessarily in first release.
	moderate (medium): Bugs that do not affect any critical user
		functionality; typically has workaround
	minor (low): Bugs that do not interfere with core functionality
		and are just annoyances that may or may not ever be fixed
	cosmetic: misspellings

Such classifications are widely used in the industry. The term "affecting users"
might apply to all of those, and even a cosmetic bug is "real".

I don't think this is about confusion, but about classification. Clearly we
don't want patches for cosmetic or minor bugs in stable releases, but where
is the cut-off point ? That may be clear for you and some of the maintainers,
but for me and probably many other maintainers, "critical" has a well defined
meaning which neither includes severe nor moderate bugs as per the classification
above.

The term "real" is much more vague and left to interpretation. My cutoff
point would be around "moderate" - it does affect users, but it is not
critical functionality. What is yours ?

Guenter

> large subsystem maintainers, based on how they submit fixes to Linus and
> to stable, view the late -rc portion as time for fixes that affect users
> and other issues like that.  So far, it's worked out pretty well and we
> don't seem to be in disagreement with Linus's view of what is a valid
> late -rc fix based on recent kernel development cycles.
> 
> The issue now is, we have maintainers who aren't sending stuff to Linus
> at all in the late -rc cycle and are relying on me to pick up things
> that are obviously "real" and "critical" fixes after .0 is out for .1
> and .2 to resolve "real" issues.
> 
> You are not one of these people, so I don't understand why you are
> getting upset and think that you somehow need to change how you mark
> stuff for stable.
> 
> The powerpc and iscsi people on the other hand, they need to look out...
> 
> chill out please and go enjoy the rest of the weekend,
> 
> greg k-h
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/