linux-kernel - Re: [PULL REQUEST] Please pull rdma.git

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <710f3e81-dd9c-8221-cf5e-7a96f4cad5b9@redhat.com>
Date:   Sat, 19 Nov 2016 18:11:22 -0500
From:   Doug Ledford <dledford@...hat.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     linux-rdma <linux-rdma@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PULL REQUEST] Please pull rdma.git

On 11/19/2016 2:46 PM, Or Gerlitz wrote:
> On Fri, Nov 18, 2016 at 4:01 AM, Doug Ledford <dledford@...hat.com> wrote:
>> On 11/17/2016 5:24 PM, Or Gerlitz wrote:
> 
> [...]
> 
>> I agree with you.  It doesn't fix your patch.  The commit message can
>> still be fixed up.
> 
>>> Please do not send it to Linus and wait for them to respond. I
>>> disagree that it fixes my commit b/c my commit was prior to when
>>> route-able RoCE  was introduced and on that time TOS had no relation.
> 
>> I agree.  A better fix tag would be the commit that added RoCEv2 support.
> 
> But this is the smaller part of the problem. The bigger part is that I
> have asked for clarifications on the patch and they didn't provide
> anything.

You asked for clarification on the commit message, I didn't hear any
objections to the content of the patch itself.

> So if you are picking patches where a reviewer comments are
> ignored, what lesson are you teaching the submitter, that he can just
> continue with this practice? why you letting this go that way?

Because I can fix up the log message at any time prior to pulling it
into my official -next branch.  Since that's all you objected to, I can
take the patch and wait for the final version of the comments.  It's not
a big deal Or.

>>> does a tiny enhancement for a 10y old commit of Roland, why you think
>>> we need it in 4.9-rc6 or 7??
> 
>> I don't, it's in the mlx-next branch which means I'll queue it up for
>> the 4.10 merge window.  I have no plan on sending that branch for 4.9-rc.
> 
> Are you going to comment on that to the submitter? if not, they are
> going to continue with this practice.

Comment on what to the submitter?  That the patch might not have been
-rc material?  I would have been OK with it around rc1 or rc2, just not
this late in the rc cycle.  In the end, I don't, nor can I, rely on
submitters to determine what's RC material and what isn't, that's what
I'm supposed to be doing.  I will always apply my own judgment on that
issue and submitters will learn over time when their patches get skipped
on any sort of a regular basis.

> How are we supposed to realize from patchworks + your github branches
> that patches that were submitted for 4.9-rc are picked for 4.10? this
> is very confusing and error prone too.

I emailed the submitters off list about it and provided them a list of
what patches went where and why.

> Please comment also on the bunch of patches I pointed you where the
> copy you have picked into your tree (pulled it from somewhere?) isn't
> what was submitted.

I'm sorry, but you'll have to refresh my memory on this issue.


-- 
Doug Ledford <dledford@...hat.com>
    GPG Key ID: 0E572FDD



Download attachment "signature.asc" of type "application/pgp-signature" (885 bytes)