Re: [PATCH] [USB] UASP: USB Attached SCSI (UAS) protocol driver

[Luben Tuikov]

--- On Mon, 12/13/10, Matthew Dharm <mdharm-kernel@xxxxxxxxxxxxxxxxxx> wrote:
> Your insinuations against the character of many
> long-standing Linux
> developers, based on their refusal to accept your
> submission,

No, not submission. The fact is that no one bothered to review the code. It was simply flat out NAK-ed it in just four minutes, fronting one of their co-workers with the defunct driver already in.

It would've been a different story if Greg, Alan and you and anyone else willing, had provided a technical review, and /then/ reject it--the rejection reason would've been clearer to everyone, than taking all this thread to get to.

Greg didn't review it and rejected it 4 minutes after posting. Alan didn't review it and after I posted the 18 technical reasons (my 2nd post in this thread replying to Greg's) said this:
> Your driver may be the best on the planet - who knows - 
Obviously he didn't review it.
You, after I posted the driver and the 18 technical reasons, said this:
> If, in fact, Luben's driver is somehow "better", ...
and
> ... several things would have to be true.  I do not know if they are true here, ...
and
> That said, unless the current driver is really bad, and Luben's is tremendously better,

These are from this very thread.

> are simply
> beyond the pale.  I could just as easily make every
> one of these
> accusations against you -- who pays your salary, for
> example?  What are
> their interests?  You make claims about your
> motivations, but how am I to
> verify any of those?

I've already stated that there had never been an agenda about uasp.c and Linux. The uasp.c driver was written over most of a Saturday (when I had time and uas.c showed itself to be defunct).  Since uasp.c is a working driver and correctly implemented in terms of UAS, USB, SCSI, the kernel and it's layers, I thought it would be *helpful* and *useful* to people--that's all.

The driver was rejected flat out only after 4 minutes after submission claiming that there is a driver in the kernel that "does the exact same thing".  I then provided 18 technical reasons as to why uas.c does NOT in fact do the exact same thing to which Greg responded with:

> But again, this driver is not acceptable as-is, sorry.

Why would he have to apologize? Anyway, to which you responded with not knowing which driver is good.

> The linux community works because it is exactly that -- a
> community.  We
> have, just like any other community, standards of
> decorum.  You have
> violated those standards, repeatedly, despite several
> people politely
> telling you the proper manner in which to behave.

When people read "the community" responses in these mailing lists, they think "Wow what a benevolent bunch of people" and "look, they just wanna help". But what this mailing list doesn't show is that this is a very close knit of people who work for the same company (or two) and who go to Linux conferences religiously and are very close buddies. Obviously uasp.c didn't stand a chance _and_ was rejected in just 4 minutes, without a technical review. As you can see in this thread the three of you kept fronting the uas.c driver despite the 18 technical reasons I posted and the fact that it's badly written, and needs to be replaced with something that works, as people will find out when UAS devices make it to market. It's all in the beginning of this thread, start reading here:
http://marc.info/?t=129165521000011&r=2&w=2

So after such a blatant refusal to even give a technical review of the driver, it had me thinking: why would that be?

> > Did you review my driver? Did anyone else in this
> thread? No, of course
> > not. You didn't even do it the second time I called
> your bluff in this
> > thread. Why not? Simple, it's not what you're getting
> paid to do now.
> 
> *bzzt*  Wrong.  I did review your driver.  I
> found it interesting, but upon
> first submission I found no compelling reason to prefer it
> over the old.
> Your initial submission gave no such reasons.

If you reviewed it, then why did you write that you had no idea if the driver were good or not? Here is what you wrote in this very thread:

> If, in fact, Luben's driver is somehow "better", ...
and
> ... several things would have to be true.  I do not know if they are true here, ...
and
> That said, unless the current driver is really bad, and Luben's is tremendously better,

Your full message can be found here: http://marc.info/?l=linux-kernel&m=129186163519728&w=2.

But now you say that you had reviewed it!? Now you say you found the driver "interesting" but "no compelling reason to prefer it over the old". How about that it works? How about the 18 technical reasons I posted *before* you posted your response quoted above (which reasons you had read)?  You didn't address any of them.

> It was only until, after your submission was refused,

It was flat out refused only 4 minutes after I submitted it.

> that
> you addressed
> the technical merits of your driver over the existing
> one.

The reason I posted the 18 technical reasons, is because Greg claimed that uas.c "does the exact same thing". His response is here: http://marc.info/?l=linux-usb&m=129165544600441&w=2, he posted this only 4 minutes after I posted the driver. I therefore decided to clarify that uas.c does NOT in fact do the "exact same thing", and backed that up with the 18 technical points.

> I will admit,
> you have some valid technical points.  But, they are
> completely overridden
> by your inability to work within the standards of behavior
> of the community.

What does this actually mean? I just posted my uasp.c driver in this very thread and it got rejected 4 minutes afterwards without technical review. When I followed up with a technical review you say "your inability to work within the standards of behavior of the community".

Does providing no technical review and flat out rejecting a driver fall into your "inability to work within the standards of behavior of the community" definition?

> If, at any time, you had decided to stop using ad-hominem
> attacks and
> instead made a calm, composed, and well-reasoned statement
> about why the
> work to fixup the existing driver would be worse than doing

1. The whole thing should be ripped out. Any good work would change 100% of the driver as uasp.c shows (essentially getting a new driver in).
2. I did make that "statement" in the 18 technical reasons of why uasp.c was better than uas.c, other than "it works" of course.

> a drop-in
> replacement, we would have listened.

I did. In the 18 technical reasons I listed in this very thread. Here is the link: http://marc.info/?l=linux-kernel&m=129185378712222&w=2

> You came pretty
> close to doing this,
> but seemed completely unable to resist personal attacks
> against members of
> this community.

And those are? I think you're priming up here what people should think.

> And you never really addressed,
> beyond a 1-line statement
> stating that to fixup the existing driver you would need to
> replace it
> wholesale, why working to improve the existing driver is a
> bad choice.

I said that in the 18 technical reasons I listed, link above.  The existing driver is badly written, the infrastructure is just off.

> We look to submitters to maintain their work.  Yes,
> there are apparently
> some difficulties getting Matt W. to push the ball forward
> on his UAS
> driver.

It's simple, rip out uas.c and put in uasp.c and give people something working and let everyone contribute to something with good foundation.

> However, dealing with you is comparable to
> drinking napalm; I
> would much rather deal with someone who is
> less-than-responsive rather than
> someone who is abrasive.

Actually, it's very easy to deal with me. When people come to me, I say "What can I do to help you?" and then I provide them a solution and always go the extra mile, and give them something constructive they can use, and I say, "here it is, and I did this extra thing and let me know what else I can do for you."  Most of the time I don't wait for people to come to ask me, but proactively contribute to the end goal, surprising people with "it's already done" when they ask for it.

   Luben

--
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/