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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Sep 2010 01:47:42 +0400
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	James Bottomley <James.Bottomley@...e.de>
CC:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Dirk Meister <dmeister@...-paderborn.de>,
	linux-scsi@...r.kernel.org, Chetan Loke <chetanloke@...il.com>,
	Chetan Loke <generationgnu@...oo.com>,
	scst-devel <scst-devel@...ts.sourceforge.net>,
	linux-kernel@...r.kernel.org, Mike Christie <michaelc@...wisc.edu>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Subject: Re: [Scst-devel] Fwd: Re: linuxcon 2010...

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.

> Since patches into SCSI go over the mailing list for review and
> integration (and running checkpatch.pl on ... this would be a hint), I
> don't really give a toss how they're generated.

Great to hear that! Thanks!

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