On 01/23/2016 02:02 PM, Linus Torvalds wrote: > On Sat, Jan 23, 2016 at 8:16 AM, Doug Ledford wrote: > >> I don't think it's as "clearly not ready" as you think, but that's just >> my opinion ;-) > > So how ready and stable is this? IOW, if I do this pull, can I rely on > that being "it", and really just get fixes. I still want to send the staging changes. But those are actually very small: there are three drivers in staging/rdma that we put there as a deprecation step and that need to be deleted, and I need to update the maintainers file to exclude staging/rdma from the directory list for the primary staging area so people quit sending patches for it to the normal staging mailing list. The problem we had with staging/rdma is that it's waffled back and forth as to whether Greg or I would handle the patches, but the hfi1 driver is now at a point where it needs to have its patches coordinated with patches in the main rdma tree, and so it was agreed that I would take over staging/rdma and Greg would ignore it, but Greg needed to go ahead and push through all of his staged changes before we put that in place and I'll take over starting with the next for-next cycle. Otherwise, yes, the pull request I sent you is "it" for this release. I have no other queued series or misc items, everything else is relegated to for-next status (of which I have quite a few of those and probably need to open my for-next quickly anyway). > One of the reasons I absolutely detest the "last Friday" pull requests > is that it really tends to smell like "this pull request was hurried > to hit the merge window". I tried to carefully select what I felt was ready versus should wait when I processed patches upon my return from PTO. There are 171 patches total in the pull request. Of those, 99 have been there since before Dec. 24th. There were 57 that I processed on Monday and Tuesday when I got back from PTO. That broke down to 34 one off patches that include a smattering of things like sparse and other checker fixes, actual oops fixes, and cleanups; 12 patches for the NFSoRDMA stack that were previously in Bruce's tree; and a series specific to the mlx4 driver. I let this sit specifically for linux-next automated runs. On Thursday I decided to take a series I had previously skipped (support for raw QP types in the mlx5 driver) and I took one fix I had previously missed and was brought to my attention, and I took one fix that didn't get authored until that morning and needs to go into your tree even if the rest of the pull request doesn't. I then let that sit overnight again just to get another round of linux-next testing. It goes without saying that I got positive 0day results on all of these, and generally much faster than waiting overnight and checking to see if any failure messages came back. > I much prefer seeing early pull requests > because that just shows that the subsystem is on top of the timing. > And that in turn means that I also get that warm and fuzzy feeling > that if the subsystem has its act together, I'll be getting just fixes > after the merge window is over. > > (The _other_ reason I don't like the last-Friday pull requests and > prefer the early ones is that then I'm not hurried, and I can take my > time and do the pull requests in sensible groups - filesystems > together etc) > > So if I end up pulling this, can I rely on getting just fixes for the > next ~6-7 weeks? Yes, that much I can assure you. And if you don't take it, I can also attest that there will be roughly 20 fixes coming your way shortly ;-) -- Doug Ledford GPG KeyID: 0E572FDD