The case of the supersized shebang

Leaving aside the initial regression (the #! line has always been prone to truncation; as other comments say it used to be truncated earlier in older Unixes, and older software like perl has workarounds for this for decades), the discussion about the regression induced in *stable* kernels is more worrying. The discussion seems to be saying "whitelisting patches for the kernel stable tree is too hard and does not scale, so let's select them automatically and then let people blacklist the ones that shouldn't be backported". The "spotting ones to blacklist" seems even less likely to reliably scale, with more false negatives ("spot the problem patch amongst the hundreds automatically added this week" missing some that should have been flagged "don't backport").

If the "stable" kernels are going to have not-manually-selected/verified changes in them, and a shorter release cycle, it seems to me they'd increasingly become "alternative bleeding edge" kernels with older features, but "assorted newer patches added in for flavour." At which point I wonder who would run them? Those wanting actual stability probably end up relying on their distro kernel teams manual review, and those wanting the bleeding edge probably want the new features too. In other words the explicit manual selection of "stable" changes, and the QA, is what makes them "stable" kernels. Which seems increasingly not to be happening with the upstream kernel stable trees, because it's a lot of work.

As a sysadmin my desire for "stable" anything is (almost) no regressions, and some fixes for critical issues. Almost by definition with a preference for stability (ie, availability/reliability) over changes.

Ewen