On Fri, Jul 12, 2013 at 11:48:01PM -0700, Greg Kroah-Hartman wrote: > > > And if something "fixes" an issue, then I want it in stable, just like > > > Linus wants that in his tree. > > > > It's the difference between "this is a fix" and "please backport this > > fix into stable". As we aid in this thread, cc:stable is a bit too much > > automatic and sometimes not appropriate (not important enough fixes). > > No, I've never said that. > > I _want_ fixes in stable trees, as they are being done to, obviously, > fix problems. So does Linus, why wouldn't a fix for something that is > an issue for someone _not_ go into his tree after -rc4? > > Ok, for some issues, they need some time to "bake" I can understand, but > that's the exception not the rule at all. I do think that most of the fixes that are sent to stable should bake a little bit more, especially the ones that are not considered critical (and that according to Linus should not be in stable). After all that's what Davem does and there are probably less reverts in the stable net tree than in others. > If a distro would pick a patch up to solve a problem for a user, and > that patch is in Linus's tree, there's almost no reason that shouldn't > also be in the stable trees. It is *my* conception of the stable branch, but I think that many people have different expectations about what should be merged or not. For example in old LTS branches, I used to merge what was relevant for servers only, because I saw no reason why an old kernel would be used on a laptop (eg: 2.4). So I always skipped wifi, alsa, drm, etc... With 2.6.32, the Debian kernel guys provided me with a lot of fixes in these areas, explaining that these fixes addressed issues that their users were facing, and they were perfectly right. It's just that I didn't expect this at all. > My issue is that people are trying to get me to take stuff that is _not_ > fixes (i.e. build errors that are impossible to hit, or \n additions to > debugging kernel messages, or pseudo-optimizations of functions). But you see, maybe the '\n' additions are important to a specific development team who relies on this all the day for their work. Importance is a relative thing by nature. But I get your point anyway. Such low general importances fixes could be marked "fix" without being marked "cc:stable" so that users can later explicitly ask for their inclusion if they're concerned. That is the way we know the problem affects some users. A few tens of the fixes that went into 2.6.32.61 were requested by users, and I would never have have picked them on my own if they hadn't asked. > The other larger issue is that people somehow are not willing to send > their valid fixes to Linus after -rc4, and they flood in during the -rc1 > merge and people expect me to backport them all into .1 because they are > lazy. I'm 100% sure this is true. Some fixes are probably written against a -next tree, and adding a tag means "it will automatically be backported, no need for a separate branch for this". > Again, specific examples are the 7 powerpc patches that are over a month > old that were marked for the stable tree, yet didn't hit Linus's tree > until now. I can dig up more examples if wanted, just look at the flood > that comes in for -rc1. > > I _should_ be seeing more patches marked for stable showing up after > -rc3 then for -rc1. As it is, I think there's something wrong with > maintainers relying on me to do their work for them too much, and it's > finally pushed me to start complaining and pushing back. I'm sure this is true. But at the same time I also think that there is a difference between what *you* expect in -stable and what Linus expects there. Linus says that something not suitable for past -rc4 has no place in -stable. You want most fixes that a distro would pick. But many of the fixes a distro would pick are probably not important enough to be picked past -rc4 and risk regressions. So these fixes are exposed to the world in -rc1 for the first time in their life, and unfortunately are merged at the same time. The problem is to find a way to mark a fix as a candidate for stable but with a reserve for some observation period. Maybe just some indication that the fix should not be backported before the version it's merged into is released ? That could make sense after all : many fixes that went into 3.11-rc1 were not important enough to go into 3.10, so they can wait for 3.11 to be released before being backported. But that requires an extra queue. Willy -- 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