Re: [Scst-devel] Fwd: Re: linuxcon 2010...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux