Date:	Sun, 05 Sep 2010 18:34:04 -0700
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	Mark Deneen <mdeneen@...il.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Mike Christie <michaelc@...wisc.edu>,
	Vladislav Bolkhovitin <vst@...b.net>,
	linux-scsi@...r.kernel.org, Chetan Loke <chetanloke@...il.com>,
	linux-kernel@...r.kernel.org,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	James Bottomley <James.Bottomley@...e.de>,
	scst-devel <scst-devel@...ts.sourceforge.net>
Subject: Re: [Scst-devel] Fwd: Re: linuxcon 2010...

On Sun, 2010-09-05 at 20:58 -0400, Mark Deneen wrote:
> > Hi Mark,
> >
> > I will always be advocating using the best tool for the job in any given
> > situation.  So absoulutely, I would have picked bitkeeper over tarballs
> > any day of the week 7 years ago, or over SVN if it had existed back
> > then.
> 
> I can't say that I agree with this.  SVN existed, along with many
> other open source choices -- the choice of BitKeeper was a mistake.
> 

Bitkeeper taught Linus by his own admission that there was actually a
reason to using a SCM for the kernel to begin with, and helped drive
some early git design princables which he also briefly mentioned in the
google git talk.

So I hardly consider this a mistake looking at it from a historical
perspective.

> > But again, I think it's an important point that git is a tool that was
> > made explictly for the linux kernel workflow.  Why would a new subsystem
> > maintainer is participates in the kernel workflow ever use anything
> > besides git at this point..?
> 
> Look, I'm not saying that I dislike git.  I use it as my SCM here.
> However, git was in its infancy (or not even around) when SCST was
> started.  It's not like they had a proprietary vendor go cold turkey
> on them, forcing everyone to another solution.

I am really sorry to hear about SCST's bad timing wrt to the evolution
of git, but I hardly see this as an acceptable excuse for poor mainline
workflow.

> 
> > And sorry, but considering the obvious advantages in terms of workflow
> > speed and flexibility that git brings to the table for a subsystem
> > maintainer, calling the choise of SCM a nit-pick item demonstrates a
> > level certain level of inexperience wrt to mainline kernel workflow.
> > Which is perfectly OK, but if you really want to understand the issues
> > at hand in a distributed vs. centrailized SCM model, I strongly suggest
> > you watch Linus's talk as well.
> >
> > Best,
> >
> > --nab
> 
> I'm still calling it a nit-pick.  Vlad could switch to git in a short
> amount of time if he felt so compelled.  This is like saying that the
> quality of a car is based on the style of garage it is parked in.
> 

Well, if we are going to start talking about car analogies, then I have
one for you.. 8-)

Using a centralized SCM for kernel subsystem workflow in the year 2010
in akin to trying to make a modification to a 18,000 RPM capable engine
in a Ferrari F1 (eg: Linux Kernel), tuned to run at the *highest* levels
of international competition (eg: LKML).  But instead of using the tools
(git) that where explictely designed the F1 engine by it's creator (eg:
Linus aka Enzo Ferrari), you end trying to adjust your F1 engine's
killowatt per litre displacement output using a broken FM tuner knob and
rusty spare tire jack from a 79' Ford Pinto.

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