It's done exactly in this way... in a sense

It's done exactly in this way... in a sense

Posted Jun 17, 2008 17:08 UTC (Tue) by khim (subscriber, #9252)
In reply to: The core issue by bojan
Parent article: Stable kernel 2.6.25.7 released

So, the best policy is just to describe them all and let people (including distributors) decide if they want to bump up or not.

Better for whom exactly? There are exist one potential group which will be VERY negatively affected: top-level kernel developers (and to lesser extent all other kernel developers). For them detailed list of security implications in descriptions is unneeded noise, not something important. They look and review THOUSANDS of such descriptions each and every week so OF COURSE they want to reduce this noise. If issue looks severe enough - they keep it in description.

In other words, if things are logged in such a way that even the pickiest of them are OK with it, then the ones that are less picky will be OK too.

And the pickiest users are of course kernel developers - they want to avoid clutter in various typed of reports and so demand short and concise descriptions. So they remove unimportant (for them) parts. Including detailed descriptions of possible security implications. In all cases except the most severe ones. So in fact they did what you asked them to do - but somehow you are not satisfied.

Now if you think they go overboard in some cases - you can join the system and help to prevent this. If you want totally different style of commit messages (extensive with lots and lots of details) in general - you are free to fork the project and put any kind of descriptions you want.

---

to post comments

> Better for whom exactly?

For people trying to keep their systems secure?

Security issues are not noise, especially when people producing patches for them are already
aware of their nature.

> So they remove unimportant (for them) parts.

Yeah, that's kinda the problem. Even the most trivial of security issues may be important to
someone. Removing information about it puts users that may be affected at a disadvantage.

> If you want totally different style of commit messages (extensive with lots and lots of
details) in general - you are free to fork the project and put any kind of descriptions you
want.

So, mentioning in the release notes of .7 that some security issues have been addressed, which
would take less than 100 words, requires a kernel fork? I don't understand where all this
hostility is coming from.

If issues are known, release notes should specify that. It's that simple.