-Greg KH has USB fixes for 3.12-final :
Here is a set of patches that revert all of the changes done to the
pl2303 USB serial driver in the 3.12-rc timeframe, as it turns out they
break some devices that work just fine on 3.11. As it’s not a good idea
to break working systems, drop them all and they will be reworked for
future kernel versions such that there is no breakage.I’ve also included a MAINTAINERS update for the USB serial subsystem and
a new device id for the ftdi_sio driver as well.
-Linus Torvalds sends an e-mail titled “Linux 3.12 released…and no merge window yet..and 4.0 plans?” :
I was vacillating whether to do an rc8 or just cut the final 3.12, but
since the biggest reason to *not* do a final release was not so much the
state of the code, as simply the fact that I’ll be traveling with very bad
internet connection next week, I didn’t really want to delay the release.
Sure, we had a number of driver reverts, and there was an annoying
auto-NUMA memory corruption fix series, but none of it was really worth
delaying 3.12 for.But the fact that I’m going to be (effectively) off-line next week means
that I’m *not* opening the merge window for 3.13 yet – since I won’t have
the bandwidth to really do merges anyway.That doesn’t mean that you can’t send me pull request for the merge window
early, of course – maintainers can *always* send their pull requests early
rather than late, if they have everything lined up and ready. But if you
have some feature that still wants polishing, you basically get a free
week to do that.So the two-week merge window for 3.13 will start a week from now. You have
an extra week. But that also means that I will be doubly disappointed in
anybody who then leaves their merge request until the *end* of that
two-week merge window.Anyway..
Onto a totally different topic: we’re getting to release numbers where I
have to take off my socks to count that high again. I’m ok with 3., but I don’t want us to get to the kinds of crazy numbers we had in
the 2.x series, so at some point we’re going to cut over from 3.x to 4.x,
just to keep the numbers small and easy to remember. We’re not there yet,
but I would actually prefer to not go into the twenties, so I can see it
happening in a year or so, and we’ll have 4.0 follow 3.19 or something
like that.Now, it’s just a number (since we’ve long since given up on
feature-related releases), and it’s at least a year away, so why do I even
mention it at all?The reason I mention it is because I’ve been mulling over something Dirk
Hohndel said during LinuxCon EU and the kernel summit. He asked at the Q&A
session whether we could do a release with just stability and bug-fixes,
and I pooh-poohed it because I didn’t see most of us having the attention
span required for that (cough*cough*moronic*woodland
creature*cough*cough).So I may be pessimistic, but I’d expect many developers would go “Let’s
hunt bugs.. Wait. Oooh, shiny” and go off doing some new feature after all
instead. Or just take that release off.But I do wonder.. Maybe it would be possible, and I’m just unfairly
projecting my own inner squirrel onto other kernel developers. If we have
enough heads-up that people *know* that for one release (and
companies/managers know that too) the only patches that get accepted are
the kind that fix bugs, maybe people really would have sufficient
attention span that it could work.And the reason I mention “4.0″ is that it would be a lovely time to do
that. Roughly a years heads-up that “ok, after 3.19 (or whatever),
we’re doing a release with *just* fixes, and then that becomes 4.0″.Comments?
Linus
-David Miller and networking :
I’m sending a pull request of these lingering bug fixes for networking
before the normal merge window material because some of this stuff I’d
like to get to -stable ASAP.1) cxgb3 stopped working on 32-bit machines, fix from Ben Hutchings.
2) Structures passed via netlink for netfilter logging are not fully
initialized. From Mathias Krause.3) Properly unlink upper openvswitch device during notifications,
from Alexei Starovoitov.4) Fix race conditions involving access to the IP compression scratch
buffer, from Michal Kubrecek.5) We don’t handle the expiration of MTU information contained in
ipv6 routes sometimes, fix from Hannes Frederic Sowa.6) With Fast Open we can miscompute the TCP SYN/ACK RTT, from Yuchung
Cheng.7) Don’t take TCP RTT sample when an ACK doesn’t acknowledge new data,
also from Yuchung Cheng.8) The decreased IPSEC garbage collection threshold causes problems
for some people, bump it back up. From Steffen Klassert.9) Fix skb->truesize calculated by tcp_tso_segment(), from Eric
Dumazet.10) flow_dissector doesn’t validate packet lengths sufficiently, from
Jason Wang.
