Read the followup by pagexec

To compound your mistake you also insult almost everyone who happens to disagree with you.

Unfortunately he is so unpleasant when doing it that virtually everyone who might benefit from his instruction is so turned off by his supercilious and venomous interaction style that they rapidly disregard everything he says, if they don't just killfile him and leave it at that.

I'm not a security person, just someone writing low-level userspace code some of which is network-exposed, i.e. just the sort of person he might be interested in educating, you'd think. When he started posting here I had no idea who he was. Within about fifty posts I'd realised that he obviously knew his stuff, but his interaction style was so unpleasant and so predicated on never admitting error and never giving anyone the benefit of the doubt that by that point I wouldn't believe him if he said the sky was blue. And I don't think I'm particularly unusual.

Even people who can cope with the... robust interactions on the l-k list get turned off by the spender style: the vast number of good developers who don't go near l-k because it's too unpleasant are not even going to consider paying attention to spender, because listening to his security lessons is like wading through acid. Nobody wants their lessons interspersed with commentary on how stupid and foolish they are, and how they are engaging in coverups against the public good (though that last is more PaXTeam's shtick). There's a reason decent teachers don't attack their students.

I have an aunt who communicates in a similar style to spender. Or she would, if she could -- nobody talks to her. Nobody wants to.

I'll note that bug fixers tend to only look back a short while when considering -stable fixes (if you look at the number of changesets in the various long-term and -stable supported kernels, you will see that they tend to get a lot of fixes initially, but that the rate of fixes tapers off fairly rapidly)

Well, that's an expected curve: current empirical studies show that the distribution / time evolution of software defects goes along a Simon-Yule distribution - which goes down sharper than a bell curve as time goes on.

It's also roughly what you get if you use a simple bug fixing model: take the set of bugs still unfixed, and let bug fixers (developers) random walk the code, then there's a fixed probability to find a bug, with every man-hour spent on looking at the code.

As time goes on, the probability increases that a bug will be found, with a 1-1/t probability, where 't' is the time spent on the code. It will be like a bell-curve for a given difficulty of bug. The 'difficulty' of bugs is a constant parameter, so the combined bug metric would show the integral of 1-d/t ('d': difficulty, 't': time), integrated over 'd' and 't', which would still roughly be a bell curve in practice.

Thus older kernels seeing fewer fixes is natural and expected and is not in itself a sign of less attention.

There's also another aspect: the Cc: stable tag does not typically limit how far a fix is getting ported back - that is decided by the -stable maintainers. They will generally port is back as far as it will still cherry-pick cleanly - and they'll notify the patch submitter if there's a conflict with older stable kernels.

But yes, the older a stable kernel is, the higher the chance that a bug is missed and is not backported - this is a classic trade-off.