Message-Id: <1283723447.556.133.camel@haakon2.linux-iscsi.org>
Date:	Sun, 05 Sep 2010 14:50:47 -0700
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Vladislav Bolkhovitin <vst@...b.net>,
	James Bottomley <James.Bottomley@...e.de>,
	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...

On Sun, 2010-09-05 at 13:18 -0700, Dmitry Torokhov wrote:
> On Thu, Sep 02, 2010 at 01:25:58PM -0700, Nicholas A. Bellinger wrote:
> > On Thu, 2010-09-02 at 23:38 +0400, Vladislav Bolkhovitin wrote:
> > > Nicholas A. Bellinger, on 08/31/2010 01:46 AM wrote:
> > > >>> It is obvious to even an casual observer from watching the TCM/LIO patch
> > > >>> series that have been flying across the linux-scsi wire the last 24
> > > >>> months that the major features (including PR and ALUA, and new fabric
> > > >>> module drivers) have been developed individual feature bit by feature
> > > >>> bit using a distributed git workflow in a bisectable manner.  Each
> > > >>> series was produced in such a manner that each patch could be reviewed
> > > >>> individually by those interested parties.
> > > >>
> > > >> That's a nice, but quite meaningless LIO advertisement. SCST is using
> > > >> the same bisectable, distributed and reviewable workflow.
> > > >
> > > > Actually, that is incorrect.  Your project uses a centralized
> > > > development model, which has it's obvious limitiations in terms of
> > > > speed, flexability, and community scale.  But really, don't take my word
> > > > for it, you can hear it for yourself directly from the horse's mouth
> > > > here:
> > > >
> > > > http://www.youtube.com/watch?v=4XpnKHJAok8
> > > >
> > > > I also very strongly suggest you find a transcript of this talk so you
> > > > can really understand what Linus means here wrt to a distributed
> > > > development workflow.
> > > 
> > > Well, Nicholas, are you really understanding what you are writing? We in 
> > > our projects have fully the same distributed (or centralized, if you 
> > > like it) development model. Have you noticed how many developers SCST 
> > > project has? We have our responsibility areas (target drivers, 
> > > scstadmin, etc.) and commit in them. The way how we get updates for the 
> > > rest of the kernel doesn't matter. Git is better for such huge projects 
> > > as the kernel, but for our relatively small and centralized by nature 
> > > due to small size (sub)projects it doesn't matter and won't bring any value.
> > > 
> > 
> > I find it hard to beleive you are actually going to agrue against a git
> > workflow for a target mode subsystem maintainer, well considering that
> > git was made by a linux kernel maintainer (Linus) for distributed linux
> > kernel development (everybody else)..?
> >
> 
> This is complete BS. Are we going to judge value of a project based on
> what kind SCM they chose to use? I guess we should ban Greg KH from
> kernel development and rip out USB and driver core layers from the
> kernel because he has the audacity to use quilt for his trees.
> 

I think the difference between what Linus says and what he actually
means in the above video could be easily misinterpreted, well especially
for some non-english speaking folks.  But I am certainly glad to see
that a russian translation is also available for this google git talk
for those who really want try to understand his reasons (and technical
requirements) for what he is saying.

So as to the specifics about why git is really the only right SCM choice
for mainline target mode maintainership, it really all comes down to
workflow.  Does your SCM allow other people to easily and without-pain
track your upstream subsystem tree changes and 'rebase' as necessary for
their patch series you make improvements..?   If we are talking about
say, a single standalone driver being developed against mainline, then
sure using a SCM like CVS or SVN is perfectly acceptable when you push
to someone upstream like gregkh or akpm via email patch attachments.

However, if we are talking about a subsystem maintainer workflow that
requires many different people to track your subsystem tree for their
own drivers and new feature bits, not being able to keep local branches
for these level developers makes their life excruciatingly painful and
unpleasent as they attempt to pull new upstream changes, especially when
the speed of new upstream development is moving quickly.  This rule
applys even more when said subsystem has a greater scope within the
source tree in question.

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.

Best,

--nab



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

Powered by blists - more mailing lists