- can we fix the bugs? obviously yes, but then we get accused of cover-ups unless we raise the roof over every single bug: and see past posts from Al Viro about why it's ridiculously impractical to go via vendor-sec for every such bug: if major kernel developers refuse to use it because it's such an embargoing straitjacket, then castigating people because they don't use it is a waste of time.
- can we change things so that the bugs aren't introduced so fast? Maybe, but so far no method has been proposed that doesn't have the kernel developers recoiling in horror, and if a magic development method was known that avoided all security holes and didn't utterly devastate development rates, everyone would already be using it. (e.g. formal proving of absolutely everything from the spec on down reduces security holes, but is horrible for development. Multi-person review of every change, a-la OpenBSD, does the same, but a chronic lack of reviewers makes that hard: and areas like mm are sufficiently subtle that few people are qualified to be reviewers at all.)
Going back to even/odd doesn't strike me as being likely to happen, given that that system was imploding under the much lower change load that preceded git. A more rapidly alternating .26-is-stable .27-is-unstable scheme might work, but I'm not sure what that means other than giving a formal number to the post-merge-window -rc1 kernel, and I'm not sure how *that* would help. (It might encourage people to test the -rcs, I suppose!)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds