linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Grover <agrover@redhat.com>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	target-devel <target-devel@vger.kernel.org>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	Ritesh Raj Sarraf <rrs@debian.org>,
	targetcli-fb-devel@lists.fedorahosted.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: targetcli -fb now also Apache 2.0 licensed
Date: Thu, 25 Jul 2013 20:31:41 -0700	[thread overview]
Message-ID: <51F1ED9D.50300@redhat.com> (raw)
In-Reply-To: <1374715140.7397.1390.camel@haakon3.risingtidesystems.com>

On 07/24/2013 06:19 PM, Nicholas A. Bellinger wrote:
> Because -fb has had close to zero peer review, and you've not solicited
> much input (none from us) before making significant changes to
> rtslib/targetcli over the past 1 1/2 years.
>
> For your own private tree this wouldn't matter.  However, for a single
> upstream tree moving forward, it seems irresponsible to just ask us to
> sign off on every decision that you've made in -fb with little external
> review or input.
>
> So, to help us get back to a community development model, please cut a
> -fb branch against upstream rtslib/configshell/targetcli, and start
> sending the series out for public review.

Hi Nick,

It's one thing to claim a prerogative of "upstream", but for this to 
make sense, there needs to be an actual community around the upstream. 
And if there's going to be submissions for review, then there needs to 
be someone in charge of the community with a high degree of skill in the 
code base. Nick you have a great deal of technical expertise around the 
C code in drivers/target, but Jerome was the one who wrote rtslib, 
targetcli, and configshell. I believe you can assess the technical 
aspects of how the user library interacts with the kernel code, but the 
maintainer should also be extremely conversant in the language the 
library is written in. In this case, Python. So it's not clear to me if 
submitting the code would actually result in meaningful code improvements.

Also, there has been no effort to sustain a community around this code. 
There is no bug tracking, no separate mailing list, no regular releases. 
Debian is running ancient, broken code because nothing's been tagged in 
over two years.

I would love to have you maintain and improve this code, but if you 
aren't then you can't just say "I'm the upstream bow to me!". We're 
shipping this code in Fedora and it needs active maintenance. Now that 
we're all on an even licensing footing, code can flow both ways, and 
even into your commercial version.

So, if you get a Pythonista to maintain upstream, and actually work to 
build a community around it, then I will play ball. But I must ask you, 
do you *really* want to maintain this? Forever? In a private thread a 
while back, RTS CEO Marc said your company's value-add was in different 
areas now. It might actually be easier for you to hire a Python person 
to reconcile targetcli-fb with your commercial needs, and then just 
track it. The objection I have with what you're asking me is that it 
feels like you're trying to get me to do that reconciliation work for 
you for free as a condition of being "upstream", and I'm not willing to 
do work that benefits only your company and not the community at large.

Regards -- Andy

  reply	other threads:[~2013-07-26  3:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-24  6:27 targetcli -fb now also Apache 2.0 licensed Andy Grover
2013-07-24 20:09 ` Nicholas A. Bellinger
2013-07-24 20:21   ` James Bottomley
2013-07-24 20:54     ` Nicholas A. Bellinger
2013-07-25  0:06       ` Andy Grover
2013-07-25  1:19         ` Nicholas A. Bellinger
2013-07-26  3:31           ` Andy Grover [this message]
2013-07-26  7:24             ` Ritesh Raj Sarraf
2013-07-26 15:18               ` Marc Fleischmann

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=51F1ED9D.50300@redhat.com \
    --to=agrover@redhat.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nab@linux-iscsi.org \
    --cc=rrs@debian.org \
    --cc=target-devel@vger.kernel.org \
    --cc=targetcli-fb-devel@lists.fedorahosted.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).