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 stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html