linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladislav Bolkhovitin <vst@vlnb.net>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: Bart Van Assche <bart.vanassche@sandisk.com>,
	"lsf-pc@lists.linux-foundation.org"
	<lsf-pc@lists.linux-foundation.org>,
	target-devel <target-devel@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [LSF/MM TOPIC] LIO/SCST Merger
Date: Thu, 28 Jan 2016 18:57:38 -0800	[thread overview]
Message-ID: <56AAD522.9050604@vlnb.net> (raw)
In-Reply-To: <1453963019.6746.244.camel@haakon3.risingtidesystems.com>

Nicholas A. Bellinger wrote on 01/27/2016 10:36 PM:
> On Wed, 2016-01-27 at 09:54 -0800, Bart Van Assche wrote:
>> Last year, during the 2015 LSF/MM summit, it has been decided that the 
>> LIO/SCST merger project should proceed by sending the functionality 
>> upstream that is present in SCST but not yet in LIO. This will help to 
>> reduce the workload of target driver maintainers that maintain a version 
>> of their target driver for both LIO and SCST (QLogic FC and FCoE target 
>> drivers, Emulex FC and FCoE target drivers, RDMA iSER target driver, 
>> RDMA SRP target driver, ...). My proposal is to organize a session 
>> during which the following is discussed:
>> * Which patches are already upstream in the context of the LIO/SCST 
>> merger project.
>> * About which patches there is agreement but that are not yet upstream.
>> * To discuss how to proceed from here and what to address first.
> 
> No, just no.  If you've not been able to articulate the specifics of
> what you're talking about to the list by now, it's never going to
> happen.
> 
> You'll recall last year how things unfolded at LSF.  You started
> comparing data structure TMR member names of no consequence to a larger
> LSF audience, and quickly tried to pivot into a discussion about adding
> hooks to LIO fabric drivers for your own out-of-tree nastiness.
> 
> I really fail to see how that helps LIO or upstream.  To repeat.  I'll
> not allow SCST's out-of-tree legacy requirements to limit LIO's future
> in upstream, and if you or your employer is still trying to get
> enterprise distros to listen to that nonsense behind the scenes, then
> please stop wasting everybody's time.
> 
> Bart, I really want to believe you and your employer have good
> intentions for LIO.  However, being one of it's largest detractors in
> the past means that you have to really put your best foot forward on
> your interaction with the LIO community.
> 
> However, your inability to ask questions before acting, refusing to
> answer to all feedback on reviews for changes of substance, and not
> following the expected patch review progress without repeatably leading
> yourself and others down the wrong path really makes me start to
> question your intentions, or at least your abilities as a kernel
> contributor.
> 
> Also, you've not managed to merge any of the outstanding ib_srpt fixes
> from the last year, which brings us to a grad total of 6 small patches
> since the original merge of ib_srpt in Oct 2011.
> 
> # git log --author=Bart --oneline -- drivers/infiniband/ulp/srpt/
> 19f5729 IB/srpt: Fix the RDMA completion handlers
> ba92999 target: Minimize SCSI header #include directives
> 2fe6e72 ib_srpt: Remove set-but-not-used variables
> 649ee05 target: Move task tag into struct se_cmd + support 64-bit tags
> afc1660 target: Remove first argument of target_{get,put}_sess_cmd()
> ab477c1 srp-target: Retry when QP creation fails with ENOMEM
> 
> That's really a terrible record.
> 
> So until you're able to demonstrate publicly to me and the LIO community
> that you do have good intentions, and not trying to rehash the same
> tired old nonsense and willful ignorance, please stop throwing out these
> generic topics as a branding exercise.
> 
> There are much more interesting and important topics at LSF to discuss.

While I'm generally refraining from feeding trolls, don't you think that a person who
has contributed you one of the major drivers and continues making such important
contributions (for free!) trying to bring (eventually, after how many years?) LIO
reliability to something you can compare to SCST, deserves a little more respect?

Vlad

      parent reply	other threads:[~2016-01-29  2:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-27 17:54 [LSF/MM TOPIC] LIO/SCST Merger Bart Van Assche
2016-01-27 18:08 ` [Lsf-pc] " James Bottomley
2016-01-27 18:19   ` Bart Van Assche
2016-01-27 18:31     ` James Bottomley
2016-01-28  6:36 ` Nicholas A. Bellinger
2016-01-28  9:01   ` Christoph Hellwig
2016-01-28 16:24     ` Sagi Grimberg
2016-01-28 16:47       ` [Lsf-pc] " James Bottomley
2016-01-28 15:34   ` Bart Van Assche
2016-02-01  2:44     ` Alex Gorbachev
2016-01-29  2:57   ` Vladislav Bolkhovitin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56AAD522.9050604@vlnb.net \
    --to=vst@vlnb.net \
    --cc=bart.vanassche@sandisk.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=nab@linux-iscsi.org \
    --cc=target-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).