On Thu, Sep 2, 2010 at 4:25 PM, Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx> wrote: > I really have no idea what you are talking about 'behind closed doors'.. > > Have you not been watching the amount of TCM/LIO patches on the > linux-scsi list for the last 18 months..? > Please don't make me go public. I'm trying to keep my mouth shut purely out of NDA. Inspite of that I've mentioned it publicly in my last emails that the decision was made ~9 months ago? Someone told me 'LIO will be merged eventually and NOT scst'. This ain't open-source development as we know it. Also there are exactly 'ZERO' users/developers yelling 'NOT' to include scst. So please stop your PR about LIO. Since no target subsystems were ever chosen, I would think that LIO's list should have some meat, no?And by now, the whole community knows that you have near to zero meaningful/technical conversations on LIO's mailing list. So I'm not sure when you talk about your git workflow and your patches, what you are actually talking about. >> >>> It is obvious to even an casual observer from watching the TCM/LIO patch >> >>> series that have been flying across the linux-scsi wire the last 24 >> >>> months that the major features (including PR and ALUA, and new fabric >> >>> module drivers) have been developed individual feature bit by feature >> >>> bit using a distributed git workflow in a bisectable manner. Each >> >>> series was produced in such a manner that each patch could be reviewed >> >>> individually by those interested parties. Nothing needs to bisected. Just go to scst's svn repo and see the checkin-flow over there if you want to satisfy your thirst. There are no rules defined whatsoever that says that the patches need to follow git-workflow. Since you are not an official kernel subsystem maintainer no need to send you patches to get a buy-in. Patches will be sent to James B and the scsi/kernel mailing list. > Again, I suggest you watch the Russian translation of that talk on > youtube and really understand what he means, aside from the insults to > subversion users. > svn is more than capable for what it is supposed to do. So no need to tutor us on the source-control. > 1) a userspace library in intrepted languages and 2) create high level > applications using said userspace libraries that allow compatiblity to > be contained in the lib below. > An average user doesn't implement storage blobs. So I don't want to worry about what they would think.This is your useless LIO PR and not a missing feature in scst. > Uhhh, I don't think so. Aside from your obvious project workflow > issues, the fact that SCST completly lacks a proper user-space driven > representation of parent / child relationships between kernel level data > structures in a fabric independent manner, while still allow for fabric > dependent groups and attributes is a most definately show-stopper for > me. > Show stopper for you? Sorry but you seem to be self-proclaimed judge/maintainer pushing/speaking your vendor's/customer's agenda. Ever noticed how screwed up the fc representations were? Take NPIV for instance. No one laid down rules at that time? And just because your so called vendor's/customer's may now be used to your LIO-way of doing things, doesn't mean the whole community should be forced to do that. > --nab Chetan Loke <English ain't my first language. I don't need any translation because I speak one language - It's, Linux! The language and choice of the GNU generation> -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
