[lkml]   [2005]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFC: Starting a stable kernel series off the 2.6 kernel
* Adrian Bunk:

> I don't get the point where the advantage is when every distribution
> creates it's own stable branches.

Different vendors have different needs WRT proprietary drivers,
experimental file systems, network stack tweaks. Their release cycles
aren't synchronized, so it's not clear at which point you can make
sorely needed architectural changes in a stable kernel series (for
example, to fix some egregious performance issues, or complicated
security issues).

> What's wrong with offering an unified branch with few regressions for
> both users and distributions?

One user's regression is another's bug fix. And where do those
regressions come from if you don't make any changes in functionality? 8-)

> It's not that every distribution will use
> it, but as soon as one or two distributions are using it the amount of
> extra work for maintaining the branch should become pretty low.

Maybe, but I don't see why a vendor should give up its kernel

You mentioned security issues in your initial post. I think it would
help immensely if security bugs would be documented properly (affected
versions, configuration requirements, attack range, loss type etc.)
when the bug is fixed, by someone who is familiar with the code.
(Currently, this information is scraped together mostly by security
folks, sometimes after considerable time has passed.) Having a
central repository with this kind of information would enable vendors
and not-quite-vendors (people who have their own set of kernels for
their machines) to address more vulnerabilties promptly, including
less critical ones.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-12-05 21:35    [W:0.229 / U:1.188 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site