On Wed, Jun 15, 2016 at 04:51:21PM +1000, Dave Chinner wrote: > > Overall the regression lived only 8 days in a single branch, I > > guess it shows that our process works rather well and limits the exposure > > to regressions. > > That it got as far as release and it took so long to get to the > upstream maintainers shows the process could do with being improved. Yep but users relying on oldest LTS usually run on servers that cannot reboot without prior planning, so in practice we know that users tend to be late by 1 week or more and often one or two versions. I'm pretty sure this is the reason why a single user reported the issue. I'm not saying this to dismiss the importance of a regression, just the fact that the zero-risk never exists and that if an issue can only be discovered in field (since the commit was backported according to the tags and that the need to adapt it was not detected during the review process), it will need one first victim to save all other users. In the end the quick enough report ensured that most 3.14 users will not have the time to upgrade to the broken version and 3.10/3.12 users will not even have the opportunity to see the issue at all. That's what I'm saying is not that bad. We could imagine some automated tests depending on the affected files and/or subsystems but it's not even certain that an automated test would have detected this one :-/ We need to thank the initial reporter here, and to encourage Brad to pass the information back ASAP next time this happens via his channel. 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