Re: [ANNOUNCE] TCM/LIO v4.0.0-rc6 for 2.6.37-rc6

[James Bottomley]

On Fri, 2010-12-17 at 22:47 +0300, Vladislav Bolkhovitin wrote:
> James Bottomley, on 12/17/2010 07:21 PM wrote:
> > On Fri, 2010-12-17 at 19:01 +0300, Vladislav Bolkhovitin wrote:
> >> James Bottomley, on 12/17/2010 06:22 PM wrote:
> >>> OK, I think this has reached the stage where it's been polished enough
> >>> outside mainline to the point where we can complete any remaining todo
> >>> items in-tree.
> >>>
> >>> So lets begin merging with the minimal target core and the TCM_Loop as
> >>> two separate commits. I think the target core may just fit under the
> >>> reflector mail length limits, but if not, you can send it as multiple
> >>> patches and I'll recombine them.
> >>
> >> Well, could somebody eventually explain what are advantages of LIO over
> >> SCST so you are choosing it?
> >>
> >> LIO is obviously worse all technically (see
> >> http://scst.sourceforge.net/comparison.html) as well as in the number of
> >> users and size of the community. Current in-rush attempts to make LIO
> >> _look_ not worse than SCST changed nothing in this area.
> > 
> > To be honest, I don't really give a toss about niche feature
> > comparisons: both products have niche features the other doesn't.  The
> > basic requirements in both products are solid.
> 
> James, sorry, but your position is weak and absurd. In it maturity,
> quality and features don't matter.

I didn't say maturity and quality, I said niche features.  Apparently
it's subjective, because both LIO and SCST think their own niche
features are essential and the other's are irrelevant.

>  Following this logic Linux kernel and
> a student's home brewed OS kernel for his PhD work are equal.

So linux did begin as a student's home brewed OS kernel ...

>  Obviously,
> this is wrong. No doubts, that all what Linux kernel can do with the
> same quality as it does can be added to the student's kernel sooner or
> later, ... but after several decades of hard work of thousands of people.

Precisely.  Or said a different way: as long as you choose the most
community oriented of competing offerings, the community will fill any
perceived gaps.  Conversely, you can destroy a project simply by
alienating the community.  That's why community is more important than
feature set.

> Moreover, isn't Linux kernel and you as a maintainer supposed to choose
> what is ALREADY the best, not what is promising to become better
> somewhen in the future? Or not become.

No, see above.  Many technically very competent potential additions to
linux have failed because of maintainer problems.

> > If the niche feature has
> > customer value, my estimation is that it can easily be added (to either
> > product).
> 
> If you eventually look on the technical comparison of SCST and LIO,
> you'll see that SCST is far ahead in practically everywhere, in any
> major area. Why not to compare yourself instead of blindly relying on
> what NicholasB and his people are chea^H^H^H^Hsaying.
> 
> >> In the resent threads how many people voted for LIO? Nobody. How many
> >> for SCST? Many. Moreover, has any real user of LIO participated in those
> >> threads? None?
> > 
> > This isn't a democracy ... it's about choosing the most community
> > oriented code base so that it's easily maintainable and easy to add
> > feature requests and improvements as and when they come along.  In the
> > past six months, LIO has made genuine efforts to clean up its act,
> > streamline its code and support the other community projects that would
> > need to go above and around it.
> 
> At first, can you recall any cases where community comments to SCST were
> not addressed? All of them have been addressed and none ignored. NEVER.
> 
> Simply, LIO is very much premature code comparing to SCST. It is very
> easy to find in it simple issues to comment, hence you see the big value
> of comments.

Look, I'm not interested in the backstabbing.  *Both* projects have
fairly large user bases and businesses with revenue models built around
them, so I see that argument as a wash for both sides.

> In contrast, SCST has been maturing for many years (since 2004). It's
> polished to high finish, so you can't so easily find out something to
> improve in it. The feature requests and improvements in LIO you are
> referring simply already in SCST.
> 
> Also, doesn't the size of the community reflects how community oriented
> project is?
> 
> So far in the kernel community we see that, basically, the only person,
> Christoph Hellwig, has taken responsibility to judge and he is pushing
> LIO. Christoph is a very authoritative person, so many people are just
> following his direction not dare to object. Nobody wants to go against
> Christoph Hellwig. At max, people sending me private support e-mails
> (thanks!) writing that SCST is great and obviously receives very unfair
> treatment from the kernel maintainers.
> 
> But Christoph is a biased person. Several years ago he preferred
> blessing STGT creation instead of already well existing at that moment
> SCST. Now we know that was a wrong move and SCST was the right way to go.
> 
> Are we going to repeat that mistake again?

I don't think it was a mistake. STGT gave us the userspace modifiability
that neither LIO nor STGT offered at the time.

James

> > You seem to have spent a lot of the
> > intervening time arguing with the sysfs maintainer about why you're
> > right and he's wrong.
> 
> Well, we are making the best designed and implemented code, right?
> Aren't arguments part of this process?
> 
> Anyway, we almost finished a patch with new SCST sysfs interface, which
> should satisfy Greg KH requirements. Bart several days ago sent proposed
> new layout and Greg didn't object to it. We will send this patch in
> several days.
> 
> Vlad
> 
> --
> 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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/