Linux 3.8-rc6 Kernel Is Bigger Than Linus Would Like

[phoronix]

Phoronix: Linux 3.8-rc6 Kernel Is Bigger Than Linus Would Like

While flying over to Brussels for FOSDEM, Linus Torvalds released the sixth Linux 3.8 kernel RC. Unfortunately this weekly development release is larger than Linus would like for this late in the development cycle...

http://www.phoronix.com/vr.php?view=MTI4OTY

[schmidtbag]

I would find hundreds of patches to be a good thing, assuming they all fix or improve things instead of add new features. I think Linus should accept as many fix patches as possible.

[Apopas]

Sure but he doesn't want to miss his scuba diving...

[bridgman]

... assuming they all fix or improve things ....

Problem is that you can't make that assumption. Every project has an intrinsic "breakage rate" - I usually go with "severity-weighted number of new problems introduced by the fixes" over "severity-weighted number of fixed problems". The rate depends on code complexity, consistency of developer experience, upstream test/review procedures etc.. and is usually fairly low, but I have seen the number reach 30% in large projects with complex code (ie code which was overdue for refactoring).

When you get close to release you need to be sensitive to the chance that interaction between two or more fixes will introduce a subtle, sneaky, serious new bug which will derail the release and be difficult to trace back to a specific fix. As a consequence, well run projects either drastically reduce the number of bugs they accept as release date approaches or drastically raise the amount of upstream testing and/or review required for last minute fixes, usually a combination of both.

[garegin]

Problem is that you can't make that assumption. Every project has an intrinsic "breakage rate" - I usually go with "severity-weighted number of new problems introduced by the fixes" over "severity-weighted number of fixed problems". The rate depends on code complexity, consistency of developer experience, upstream test/review procedures etc.. and is usually fairly low, but I have seen the number reach 30% in large projects with complex code (ie code which was overdue for refactoring).

When you get close to release you need to be sensitive to the chance that interaction between two or more fixes will introduce a subtle, sneaky, serious new bug which will derail the release and be difficult to trace back to a specific fix. As a consequence, well run projects either drastically reduce the number of bugs they accept as release date approaches or drastically raise the amount of upstream testing and/or review required for last minute fixes, usually a combination of both.

Shh. Code analysis and software testing is a decade behind in FOSS land. Of corse they are in denial about it, because linuxrunssupercomputers (tm).

[BO$$]

The kernel is full of bugs anyway. Nobody tests anything these days.

[asdx]

I don't understand Linus reasoning here.

There are projects who beg for patches/contributions, and on the other hand Linus is actually unhappy that people contribute to Linux?

WTF?

Or is Linus just not happy when people send big patches during the rc releases?

[garegin]

I don't understand Linus reasoning here.

There are projects who beg for patches/contributions, and on the other hand Linus is actually unhappy that people contribute to Linux?

WTF?

Or is Linus just not happy when people send big patches during the rc releases?

his infantile BS does more harm than good to the kernel's reputation. he makes it seem that he is the only audit and he is too burdened by the "too many" term papers. what role does he play that can't be shared by anyone else other than him? i'm not gonna even go into the fact that the entire kernel development model is mentally retarded and flawed. in normal Unixes not designed by children, the kernel drivers don't have to be shoehorned into the kernel tree. so they don't have to release a new kernel every day because a guy in China patched his webcam. i still don't understand why say, on freebsd I can get the latest version of vlc, but on Debian i'm stuck with the older one because of library dependencies.

[GreatEmerald]

I don't understand Linus reasoning here.

There are projects who beg for patches/contributions, and on the other hand Linus is actually unhappy that people contribute to Linux?

WTF?

Or is Linus just not happy when people send big patches during the rc releases?

The latter. He is more than happy to accept good code when the merge window is open. RCs should be stable, thus hundreds of patches are bad, since they can not only fix, but also break things.

[ChrisXY]

i still don't understand why say, on freebsd I can get the latest version of vlc, but on Debian i'm stuck with the older one because of library dependencies.

What does this have to do with linux?

You people ranting all miss the point: This is -rc6. This should be very near to release, maybe one or two rcs away. I don't understand how someone could think lots of code changes so close to a release could be a good thing.