Linus Torvalds aveva fatto capire che la RC6 rilasciata la scorsa settimana sarebbe stata l´ultima Release Candidate del Kernel Linux  2.6.35.

E non si è smentito. Nelle scorse ore è infatti arrivato l´annuncio del rilascio della release finale del Kernel 2.6.35.

Il Changelog completo nelle info aggiuntive di questa news.

Ecco invece di seguito l´annuncio ufficiale di Torvalds:

So I said -rc6 would likely be the last -rc, and nothing happened to change my mind. 

I´d always be happier if it had been an even quieter week, but the appended Shortlog of changes since rc6 doesn´t contain anything earth shaking, and I don´t think we´d have been any better offby another rc, and waiting one more week. So 2.6.35 is out, go checkit out.

This may have been a fairly odd release cycle with my rather strict-rc rules before -rc3, but on the whole I think I liked it, and it seems to have worked out ok. I relaxed my extreme stance after gettingback from vacation, so the latter half of the rc series was morenormal. But even then I got the feeling that people were perhaps a bit more aware of the whole "regression fixes only" model, which is allgood. It´s a bit hard to judge, but there are some numbers to back itup: in the 2.6.34 release, there were 3800 commits after -rc1, but inthe current 35 release cycle we had less than 2000.Now, admittedly 34 was worse than average in that respect (3800commits is a _lot_ of work after -rc1), but git history says that atleast going back to 2.6.24, we´ve never had less than 2000 commitsafter -rc1 before now. They tend to be in the 2700-3200 commit range.

So I do think we really did have a lot less churn than usual post-merge-window. And that´s good. So I´d like to try to repeat the experiment for the next release cycle, and be pretty hardnosed about taking patches and git pull requests after the merge window closes.

Talking about the next merge window: Andrew Morton was pretty unhappy with the stability of linux-next at least a couple of weeks ago. It´swhat he bases his -mm trees on, and so an unstable linux-next makes ithard for Andrew to get his work done. It also makes me worried,because a lot of people seem to think that "it´s been in linux-next for several months" means that something can and should be merged. Andif linux-next ends up being really flaky, that clearly cannot be thecase. So guys - please don´t treat linux-next as a dumping ground.

Things that go in there should be more or less ready for merging (with anemphasis on "more"), and we need to keep that tree in working order.If you´re nervous about the stability of your work, you should just admit that it´s not ready to be merged, shouldn´t go in the next release cycle, and shouldn´t be in linux-next yet and make life harder for people like Andrew - or for the other more careful linux-next submitters.

On a slightly happier note: one thing I do hope we can merge in the upcoming merge window is Nick Piggin´s cool VFS scalability series. I´ve been using it on my own machine, and gone through all the commits (not that I shouldn´t go through some of them some more), and am personally really excited about it. It´s seldom we see major performance improvements in core code that are quite that noticeable,and Nick´s whole RCU pathname lookup in particular just tickles mepink.

Anything else? I´m sure there´s tons of things I should say about what went into 2.6.35, but as usual there are already better writeups aboutwhat has changed. Things like the kernel newbies pages etc. So head off to.

Linus