Even for trends they're problematic: at most it gives you trends in what
gets publicly reported as security bugs; this is a level removed from the
kinds of things you would actually want to know.
My personal preference was for the odd/even development model. The current
model is unsustainable from a security perspective -- but there's no
interest in changing from that model, so suggesting a change of models
isn't useful. In other words, I realize the model won't change, so I'm
merely pointing out the problem with it and suggesting that at least
*something* be done about the security aspect. The current official view
is simply to "fix bugs" and not treat security bugs as special in any way.
With that kind of view, things will only decline.
We had previously extensively discussed changes that could be made to the
process so that at least security related bugs would be reported with more
accuracy and consistency, but instead it was decided to go backwards
instead of forwards. So my post wasn't really a request for change but
more of a "why are you surprised that it's so horrible?", since several
people have been pointing it out for years, and it continues to get worse.
At this point, I don't know what to tell you other than you should have
spoke up last month before they began their anti-security campaign. If you
want to find out what things you were vulnerable to, you'll have to
discover that information on your own by investigating each patch. If you
want to improve the security of the kernel in some way, you'll have to do
that yourself as well -- nobody seems to take it seriously.
Since you asked though about what can be done to improve kernel security,
one route is to remove the exploitability of certain bugclasses. The PaX
team recently has added a feature which prevents exploitation of refcount-
based bugs (like the ptrace ones listed in the CVEs in this article). So
there are always things that can be done with negligible impact, but don't
hold your breath waiting for it to come from the kernel developers