Linux: 2.6.19-rc1, Merge Window Closed

Submitted by Jeremy
on October 5, 2006 - 2:28am

Linus Torvalds released the 2.6.19-rc1 patch noting that for a number of reasons it was larger than usual, "it's a huge thing with tons of changes". He described what's in the patch, "I think we got updates to pretty much all of the active architectures, we've got VM changes (dirty shared page tracking, for example), we've got networking, drivers, you name it." A page in the KernelNewbies wiki tracks changes going into the upcoming 2.6.19 kernel.

Linus went on to note, "the shortlog and the diffstats are too big to make the kernel mailing list, but even just the summary says something:

4998 total commits
6535 files changed, 414890 insertions(+), 233881 deletions(-)

so please give it a good testing, and let's see if there are any regressions."


From: Linus Torvalds [email blocked]
To: Linux Kernel Mailing List [email blocked]
Subject: Merge window closed: v2.6.19-rc1
Date:	Wed, 4 Oct 2006 20:29:16 -0700 (PDT)


Ok, it's two weeks since v2.6.18, and as a result I've cut a -rc1 release.

As usual for -rc1 with a lot of pending merges, it's a huge thing with 
tons of changes, and in fact since 2.6.18 took longer than normal due to 
me traveling (and others probably also being on vacations), it's possibly 
even larger than usual.

I think we got updates to pretty much all of the active architectures, 
we've got VM changes (dirty shared page tracking, for example), we've got 
networking, drivers, you name it. Even the shortlog and the diffstats are 
too big to make the kernel mailing list, but even just the summary says 
something:

 4998 total commits
 6535 files changed, 414890 insertions(+), 233881 deletions(-)

so please give it a good testing, and let's see if there are any 
regressions.

As usual, the best way to get some grip on a particular subsystem would 
tend to be with some script like

	git log --no-merges v2.6.18.. drivers/usb | git shortlog | less -S 

which gives a more manageable overview of any particular area you're 
interested in (in the example that would be 'drivers/usb', but you can 
use this to browse any interesting area).

			Linus

Related Links:

lol

Anonymous (not verified)
on
October 5, 2006 - 6:52am

I just double plus love how we started to use the word regression instead of bug.

regression

Anonymous (not verified)
on
October 5, 2006 - 9:07am

Well, to be totally fair, a regressions is a specific type of bug (as regress implies, it is one that has come back). However, if you read his email that way, it would imply that he doesn't care about bugs in the new code or bugs that have continued to exist in the old code.

So, basically, you are right. Why did I bother to write this? : )

Regression, Not Bug

Inhibit (not verified)
on
October 5, 2006 - 4:41pm

He's saying to check for regressions in the code to make sure (like the poster below points out) something that was working hasn't *stopped* working. Which would be a regression.

I'm assuming that they're not putting known buggy, non-working code into the Linus tree. So there's an assumption that the problems experienced would be failures of something that was known to be working, not a flat out non-working piece of programming to begin with.

There are experimental kernels and patch sets for that type of testing.

It's very important to make a

Anonymous (not verified)
on
October 5, 2006 - 9:22am

It's very important to make a difference between "bugs" and "bugs that are regressions".

"Regressions" happen when something that worked stops working (fe: software suspend in some computer). Bugs that happen in new code or that just didn't happened in the past are different.

If you have no regressions and fix the exiting ones it's great, because it means your kernel gets stabler, even if the new features are somewhat buggy

regressions

on
October 5, 2006 - 10:52am

Agreed. Fixing regressions comes under the Hippocratic heading of "First, do no harm."

regression is a subset of bug

Anonymous (not verified)
on
October 5, 2006 - 11:22am

A regression is a *new* bug whereby something that once worked no longer works.

Subtle, but important distinction.... it's fairly common to know that you have some bugs not all of which are fixed and you might have a plan to fix them over the next x years. The important thing when you have such a plan is that you aren't introducing *new* bugs into things that already marked as "working".

ext4

Anonymous (not verified)
on
October 12, 2006 - 9:19am

I'm i wrong, or today ext4 entered the mainline kernel ?

Yes

on
October 12, 2006 - 12:18pm

Yes, to gather wider audience in *testing*. It's still in development neverthless.

--
:wq

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.