On 05/02/2013 07:21 PM, Nicholas A. Bellinger wrote:
The confusion is from rtslib-fb breaking consumer code based on upstream
rtslib for end users.
Instead of apologies, I'd much rather hear about fixing that specific
bug, and how merging useful pieces of -fb back into upstream
rtslib/targetcli might work.
Sorry, which bug?
For merging -fb into your repo, what exactly is preventing it getting
merged? I thought it was licensing, not logistics.
You know that upstream rtslib/configshell/targetcli git trees allows
anyone to 'make release' a new release tarball, right..?
Against what tag?
I've asked multiple times before to send patches to target-devel for
review, but you continue to make lots of changes without any external
external review or input from Jerome or myself.
So you *want* -fb patches posted here? I thought that would create more
confusion between the two.
Also, it might be worthwhile to CC' one of us before removing the
ability of external fabric specs to function with future -> yet-to-be
created target drivers without an automatic user-space code rev.
Well I was hesitant, which is why it took me 18 months to work up to
removing them. I didn't see a benefit that justified the added
complexity. Specs were packaged along with the python, not separately,
so adding a spec would still require a new package version.
and a continuing devaluation of potential contributors by insisting on
licensing advantages for the initial copyright holder.
Correct, that is what it takes in the real world for a small company to
support development costs for certain aspects of the free software that
you benefit from and enjoy today.
I don't necessarily buy this, but you understand why this bugged me so
much, right? RTS got something into the kernel under a given license,
and then required more favorable terms for contributions to the thing
needed (not strictly but practically) to use the kernel code. That
doesn't fly.
Changing to a permissive license has always been one of the long-term
goals for upstream rtslib/configshell/targetcli code, and we're now
strongly considering doing that with Openstack.
Ah! Ok! Well, great, please do.
Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
