On Thu, 2013-05-02 at 12:57 -0700, Andy Grover wrote: > On 05/02/2013 11:46 AM, Nicholas A. Bellinger wrote: > > As a matter of fact, yes, it is 'bogus'. > > > > It's bogus because it was being portrayed as the official upstream on > > python.org, without ever asking Jerome or myself if that was OK. > > [note altered From, I'm not speaking for my employer] > > Well no. See https://pypi.python.org/pypi/rtslib-fb , the explanatory > text was exactly the same when it was at the old URL. Seriously, I was > not trying to be sneaky. I'm sorry I made that mistake, I'm sorry for > any confusion it caused. I realize this is not the ideal situation and > I'm trying to make things as clear as possible given the fork. > 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. > > In the future, please avoid making decisions in private wrt to upstream > > rtslib/configshell/targetcli that effect the entire ecosystem if your > > not going to consider the ramifications of your actions all the way > > through. > > There is no bug tracking, no source tarballs, no > recent git tags, no separate mailing list, You know that upstream rtslib/configshell/targetcli git trees allows anyone to 'make release' a new release tarball, right..? When people have a bug with upstream today they go ahead contact target-devel directly. Has this actually been a problem so far..? > no discussion of patches, 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. 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. A discussion before fucking that up in -fb might have saved you the extra trouble. > 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. But really, the claim that a downstream AGPL fork is somehow "more free" than the original work has always been awfully lame. 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. > You had me rename the package on pypi but you haven't put up anything > in its place. No wonder people are confused. Release tarballs will be on pypi once Jerome is happy and we're done making new changes for v3.10 kernel code. > > Recently I've started a separate targetcli-fb mailing list[1]. I'd like > RTS to do the same, so we can keep target-devel focused exclusively on > the kernel code. We seem to do okay when things stay focused on the > kernel code. > If folks don't like user-space patches + discussion on target-devel they can configure a filter. --nab -- 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
