Linux Kernel 2.6.
Tomasz Torcz
2.6.13 (2005.08.28)
There it is. The most painful part of 2.6.13 is likely to be the fact that we made x86 use the generic PCI bus setup code for assigning unassigned resources. That uncovered rather a lot of nasty small details, but should also mean that a lot of laptops in particular should be able to discover PCI devices behind bridges that the BIOS hasn't set up. We've hopefully fixed up all the problems that the longish -rc series showed, and it shouldn't be that painful, but if you have device problems, please make a report that at a minimum contains the unified diff of the output of "lspci -vvx" running on 2.6.12 vs 2.6.13. That might give us some clues. The changes since -rc7 are pretty small, full shortlog and diffstat of that appended. As to the new world order: I'm actually going to be away for most of next week, but in general we should now try to do all major merges within the first two weeks of the release. After that, we go into calm-down mode, and if you have work that didn't make the cut, you get to wait until 2.6.14. The plan is that this should bring in the time between releases, so that even stuff that misses the deadline won't have to wait _too_ long for the next one. LinusChangelog
2.6.13-rc7 (2005..08.23)
Hullo. I really wanted to release a 2.6.13, but there's been enough changes while we've been waiting for other issues to resolve that I think it's best to do a -rc7 first. Most of the -rc7 changes are pretty trivial, either one-liners or affecting some particular specific driver or unusual configuration. The shortlog (appended) should give a pretty good idea of what's up. LinusChangelog
2.6.13-rc6 (2005.08.07)
James and gang found the aic7xxx slowdown that happened after 2.6.12, and we'd like to get particular testing that it's fixed, so if you have a relevant machine, please do test this. There are other fixes too, a number of them reverting (at least for now) patches that people had problems with. In general, anybody who has reported regressions since 2.6.12, please re-test with -rc6 and report back (even if, or perhaps _particularly_ if, no change to the regression). Apart from some reverts and the aic7xxx performance regression fix, there's arm and ppc updates, and some PCI resource allocation updates that hopefully will reduce the number of machines (especially laptopns) that have strange undocumented MB devices that clash in PCI IO space.. And various small one-liners. The appended shortlog/diffstat gives more some more specific insight.. LinusChangelog
2.6.13-rc5 (2005.08.02)
Ok, one more in the series towards final 2.6.13. This one is small enough that both shortlog and diffstat fit comfortably: no big architecture updates or anything like that. Some input, x86-64 and ppc updates, and various fairly small fixes in random places. Some reverts back to 2.6.12 behaviour - you've seen the discussions, and I'm sure we'll end up discussing things further for a long while still, but the plan is to release 2.6.13 with known behaviour characteristics. Give it a good testing, I'm hoping this can really turn into 2.6.13. LinusChangelog
2.6.13-rc4 (2005.07.28)
Hey everybody, as many of you are aware, we were talking (not enough) about the release process at LKS this year. This ain't it. This is just the regular old release "process", with some LKS backlog put in for good measure. But the good news is, that I'll try the new release process after 2.6.13 is out, which is hopefully not too far away. Which means that we should try to let people know about the fact that if they want to merge stuff, they should do so in the first two weeks after the 2.6.13 release, and no later (also, no earlier either, by now). So if you have a favourite kernel developer, please wake him up with a friendly kick to the head and explain this concept to him in small easy-to-understand words, and tell him that we're in the freeze process for 2.6.13 now, and that he should be gathering up the patches, and make sure they get to me _after_ 2.6.13 is out, but at that point do it in a timely manner. Ok? In the meantime, here's the 2.6.13-rc4 update, with a diffstat so horribly ugly that I won't even show it (the kernel list would eat it as too big anyway), and I'll have to go fix my code that generates it. Oh, and in case you wonder, it's ugly because a cris architecture update with long filenames that really causes git-apply to output som rather nasty-looking diffstats ;) ALSA, IB, NTFS, SCSI (qla2xxx) and the cris architecture update. LinusChangelog
2.6.13-rc3 (2005.07.12)
Yes, it's _really_ -rc3 this time, never mind the confusion with the commit message last time (when the Makefile clearly said -rc2, but my over-eager fingers had typed in a commit message saying -rc3). There's a bit more changes here than I would like, but I'm putting my foot down now. Not only are a lot of people going to be gone next week for LKS and OLS, but we've gotten enough stuff for 2.6.13, and we need to calm down. Admittedly the diff looks a bit bigger than it really conceptually is, partly due to the hwmon drivers moving around, partly due to re-indenting reiserfs. No real changes, but huge diffs in both cases. I think the shortlog speaks for itself. LinusChangelog
2.6.13-rc2 (2005.07.05)
Ok, -rc3 is pretty small, with the bulk of the diff being some defconfig updates, and cleanup of xtensa (notably removal of another copy of zlib). But there are ia64/arm/ppc64 updates and the TSO update from Davem is probably worth pointing out to people. And various smaller things which are more easily just seen from the shortlog. Among the one-liners of note is the silly block level spinlock bugfix that obviously hit -rc1 and made itself felt on SMP and preempt under moderate IO loads. LinusChangelog
2.6.13-rc1 (2005.06.28)
Ok, guys, there was a lot of stuff pending after 2.6.12, and in the week and a half since the release, the current diff against it has grown to almost three megabytes compressed. Which is actually normal for a -rc1 release judging by the two last ones, but it usually takes us longer than ten days to get there. Which just shows that 2.6.12 was brewing for too long, but we can also think positively and say that perhaps it also seems to imply that this git thing is working out and not slowing people down. Anyway, I really don't want to drag out 2.6.13 as long as 2.6.12 took, and we don't have any reason to anyway, so let's try to see if we can calm things down again, and people who are thinking about writing new code might think about spending some quality time looking at the existing code and patches instead. Now, that big patch ends up being spread out over 2069 commits, and a noticeable chunk of it is actually the new xtensa architecture that got merged, but that still leaves a lot of patches all over the place (things like a few new console fonts, for example ;). The shortlog is over 100kB in size, which means that I think linux-kernel won't take it if I include it here, so I won't. Similarly, the diffstat is 200kB, partly because of the spread out nature of the pacthes. ARM, x86[-64], ppc, sparc updates, networking, sound, infiniband, input layer, ISDN, MD, DVB, V4L, network drivers, pcmcia, isofs, jfs, nfs, xfs, knfsd.. You name it. Git trees and traditional patches/tar-balls are out there, or at least slowly mirroring out. Go wild, LinusChangelog
Archived comments:
Cthulhu 2005-08-30 14:39:36
a ja wciaz na 2.6.10..
wojtekka 2005-08-31 13:57:17
FUSE, FUSE, FUSE! ;-)
zdzichu 2005-09-08 10:34:22
http://lkml.org/lkml/2005/9/5/214 :
ETA for 2.6.14
--------------
October 7 (wild guess, probably optimistic)
FUSE
Will merge. Am fed up with arguing - any remaining problems can be
fixed up in-tree if anyone can think of how to fix them.
Comments
Comments powered by Disqus