From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755876Ab0IFVsf (ORCPT ); Mon, 6 Sep 2010 17:48:35 -0400 Received: from moutng.kundenserver.de ([212.227.17.10]:53392 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755473Ab0IFVs3 (ORCPT ); Mon, 6 Sep 2010 17:48:29 -0400 Message-ID: <4C85617E.2080603@vlnb.net> Date: Tue, 07 Sep 2010 01:47:42 +0400 From: Vladislav Bolkhovitin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5 MIME-Version: 1.0 To: James Bottomley CC: "Nicholas A. Bellinger" , Dmitry Torokhov , Dirk Meister , linux-scsi@vger.kernel.org, Chetan Loke , Chetan Loke , scst-devel , linux-kernel@vger.kernel.org, Mike Christie , FUJITA Tomonori Subject: Re: [Scst-devel] Fwd: Re: linuxcon 2010... References: <4C76CA57.3050405@vlnb.net> <1282857806.32007.175.camel@haakon2.linux-iscsi.org> <4C79484B.3090607@vlnb.net> <1283028468.32007.357.camel@haakon2.linux-iscsi.org> <4C7C18CE.5020103@vlnb.net> <1283204792.32007.448.camel@haakon2.linux-iscsi.org> <4C7FFD1A.8090509@vlnb.net> <1283459158.5598.143.camel@haakon2.linux-iscsi.org> <20100905201802.GC18411@core.coreip.homeip.net> <1283723447.556.133.camel@haakon2.linux-iscsi.org> <20100905234134.GA17212@core.coreip.homeip.net> <1283731194.556.147.camel@haakon2.linux-iscsi.org> <1283769578.15944.1293.camel@mulgrave.site> In-Reply-To: <1283769578.15944.1293.camel@mulgrave.site> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:26AwNQxaDQkKnInuAQAHCYmhBSsENIwnZVaxFCezCA0 b4ncTLhOY7gKie14BJXnvqI6wsoMjr/r5gOZfQr/NqSkE0VVPU 0jJXZ9fPkf1tgZ/o5+iQv0Wn79ZTl237JMXmDF17SmFe2zV9xb aVTr0JWGFdEMs53xMP8girVQgQd2zHPeAJKP+NQcfo7UUUjVGu c21X1LgHAe7DWeCK+75TQ== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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