Re: [PULL REQUEST] Please pull rdma.git

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3811 bytes --]

On 01/23/2016 02:02 PM, Linus Torvalds wrote:
> On Sat, Jan 23, 2016 at 8:16 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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 <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]