On Mon, Sep 06, 2010 at 02:55:35PM -0700, Nicholas A. Bellinger wrote: > On Tue, 2010-09-07 at 01:47 +0400, Vladislav Bolkhovitin wrote: > > James Bottomley, on 09/06/2010 02:39 PM wrote: > > >>>> Anyways, if we are going to compare SCM distributed vs. centralized > > >>>> workflow in terms of kernel projects, lets please at least compare > > >>>> apples to apples here. > > >>> > > >>> No, we should not be comparing SCMs at all here but rather 2 competing > > >>> implementations based on quality of the code. You tried to bring SMC > > >>> angle in and I am saying that it is BS. > > >> > > >> Again, without getting into another pointless flamewar, I think the > > >> main point here is that a open source project using a distributed > > >> workflow (like git) has major advantages when it comes to working with a > > >> larger group of developers than a centralized model (like SVN) does. > > >> > > >> Because being a subsystem maintainer typically involves this type of > > >> complex workflow involving lots of different parties, git is a tool that > > >> was created (originally) expressely for a kernel workflow, and for those > > >> types of people it works really, really well. > > > > > > Oh, for god's sake children. Why does every LIO vs SCST discussion turn > > > into a pointless flameware over stuff no-one really cares about? If > > > none of you has anything substantive to say: don't say it. > > > > James, sorry, but you can't blame us. I keep asking for clear rules and > > don't receive much. So, there are speculations and pseudo-rules, which > > sometimes go to the absurd, as in this SVN vs Git case. No surprise > > then, that people have risen against this absurd (thanks a lot to them > > for support!). > > > > Frankly, in all the situation around Linux SCSI targets I for quite a > > long time feeling myself as a hero of a Kafka novel. Supposed to be > > goals are to have the best code doing its job the best, but on practice > > nobody cares about technical arguments and figuring out which subsystem > > is the best. Instead, everything lives it own incomprehensible life, > > where doesn't matter what you are doing, all already long ago decided > > behind your back and you will never be told why. All accurate statements > > not heard or, at best, called "handwaving", but dirty public opinion > > manipulations based on half- and less-than-half- truth have very warn > > welcome. This atmosphere is unhealthy, really. > > Sorry Vlad, but this is simply not the truth. You have had ample time > to comment on the hundreds of TCM/LIO patches posted to linux-scsi and > lkml over the last years, but you have chosen never to comment on a > *single* one then, or even on a single one now of the dozens that have > been posted in the last 3 weeks while this thread has been lumbering > forward.. > > So at this point, I will once again to refrain from any non technical > interaction with yourself. If you have geninue concerns about any of > the TCM/LIO v4 code, then I suggest that you and your devels make them > known from within threads containing [PATCH] and [RFC] tags, because I > will not be bothering with anything that does not contain comments on > creating new or improving existing design and code. > I think this is somewhat backwards... Vlad appears to be asserting that SCST is more feature-complete that LIO at this point. It also seems that LIO is somewhat younger than SCST. So at this point it might be interesting to see: 1. What are the shortcomings of SCST design compared to LIO and why LIO developers chose to come with their own solution instead of collaborating with SCST folks? 2. What features are missing from SCST that are currently available in LIO? Once this is sorted out and [most] everyone agrees that LIO is indeed technically superior (even if maybe not as mature yet) solution, then it would make sense to request SCST developers to go to file/line depth of the review. Thanks. -- Dmitry -- 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
