On 01/24/2014 02:27 AM, Ingo Molnar wrote: > * John Stultz <john.stultz@xxxxxxxxxx> wrote: >> [...] >> >> I'd argue these were non-urgent fixes that should still be >> backported to -stable. > No such thing exists really. Linus argued this repeatedly: if you > think it's not urgent enough for current -git then it's doubly not > urgent enough for -stable! > > So my suggestion for the future: such fixes need to go to -git as > well, even if they seem difficult and late. Merging via the merge > window and then backporting is a generally harmful practice. So I think the difficulty here, for many maintainers who want to take a conservative approach and not be trying to squeeze non-critical fixes in right before a release, is how exactly is this a harmful process? If a issue has been around for a year, it doesn't really matter if it goes upstream this release or the next. Making sure they get widely tested via the -rc cycle seems like a much better approach. But depriving -stable of these fixes seems strange. > The fact that Greg is a soft hearted maintainer while Linus pushes > back strongly, in Finnish if needed, does not make this approach > right. I don't know how much I buy Greg as being some sort of pushover.. but I can imagine some world where maintainers are trying to short-cut Linus to get really-urgent fixes into the release by "sneaking" them into a merge window and then back via Greg. But that's sort of a paranoid way of looking at things, and isn't at all what I'm trying to do. I think part of the issue here is the lack of distinction between the last-release -stable and -longterm kernels. For non-urgent fixes I agree getting the patches into the most recent release isn't really that important (after all, they weren't important enough to make it in at -rc6 or whatever). But there are good fixes that shouldn't be withheld from folks who are running the long-term stable kernels. So I can see I have made a mistake here: In trying to be helpful testing cc:stable patches against their target trees and submitting the patches against the most-recent release right after things were merged via the normal merge window, it does create an appearance that these are overly urgent issues that should have gone in via timers/urgent. That really isn't the case here. The whole reason I took this route, is because I really want to be conservative with patches. I want lots of wide testing and no last-minute breakage. I'd much prefer the fixes have time to stew upstream before going to -stable, and am even fine if they skip the 3.13 stable tree entirely. Really if it weren't for the fact that I noticed one of the upstreamed cc:stable patches needed a small fix that ended up in the following non-stable appropriate change, I probably would have sat on my hands here and let Greg pull things in whenever. But in trying to be a helpful eager-beaver, I just caused more trouble. That said, I do think most of these should go back to 3.10 and a smaller subset to 3.4. Again, there's no urgent rush there, but I'd like to see the issue fixed. The difficult part here is that its much easier to do the backporting of fixes to -stable right after the patches have been merged and the issues are relatively fresh in my head. If I wait too long, then its more likely I'll forget a fix was needed. (Fun fact: in testing the backports to 3.4, I realized a -stable fix for an issue resolved in 3.6 hadn't ever made it to 3.4! I thought it was totally resolved, but it ends up it was just hanging out in the AOSP 3.4 tree instead). > Anyway, it's water down the bridge, and I agree with you that the > -stable backport is probably justified in this particular case, > because the bugs fixed are serious enough: but it should be done after > -rc1 or -rc2, and we should also make sure this flow of commits does > not repeat in the future. So yea. I'd still like a bit of guidance, because I would still like to make sure long term stable kernels get fixes that I don't see as urgent enough to push into the current -rc series. But I also don't want to appear to be routing around the normal process because cc:'ing stable doesn't make the distinction between longterm and last-release. Because if we really can't cc stable on non-urgent fixes, it creates an anti-pattern where its really much easier for maintainers to just ignore stable all together, which makes it harder for (pushover, totally-not-physically-intimidating, never-threatening-to-not-take-your-patches-for-a-year-and-starve-your-children ;) -stable maintainers like Greg, and ends up hurting users. thanks -john -- 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