On Mon, Apr 11, 2016 at 11:35:08PM -0700, Greg KH wrote: > On Tue, Apr 12, 2016 at 08:22:37AM +0200, Willy Tarreau wrote: > > I think we may have more of an issue educating our users than an issue > > with the code we distribute. > > I think that's the issue here, combined with users that just don't want > to upgrade as it's "hard" for them. There's nothing we can do about > making it easier than we already do, and really, taking 200 patches is > just the same work for them to take 100 patches in a release, so I > don't buy the "I only want a small subset of fixes" argument, as it > doesn't make any sense. I've already met people who used to estimate the need for each patch individually. In the end they face many more problems in production than any other user just because they drop the important ones or those that enable certain "security" fixes to work reliably. Most often it's a way for them to secure their job because nobody else can do this work around them. When they leave the team, their boss generally decides to go to regular distros with their simple update process in the end. > So I worry that this tree will give people a _false_ sense of security, > thinking that they have properly covered the needed fixes when really, > there are lots of fixes they didn't even know they needed that got > applied to the "normal" stable tree for issues they will hit. Also the stable tree gets fixed thanks to feedback from users. When we do something wrong it doesn't last long. > Also, people need to stop being afraid of the large numbers of stable > patches, and compare it to the overall % of changes, and realize that > what we take in stable releases is really a trivially small number of > the overall changes made to the kernel. Yep. As a rule of thumb, I'd rather recommend people who fear updates to always stay late by 2-3 versions and monitor the more recent changelogs for possible fixes for previous versions. That might possibly make them more comfortable. It's not a good practice but it's already better than not applying the required fixes at all. And let me restate it, most of us are our own users. We *are* careful. My company ships load balancers which achieve multi-year uptimes (when people don't reboot to apply fixes). We don't want to mess up with a faulty update there. Ben gets his work distributed to all debian users and certainly doesn't want to take risks either. 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