Message-ID: <485A0BE8.7020306@panasas.com>
Date: Thu, 19 Jun 2008 10:34:00 +0300
From: Benny Halevy <bhalevy@panasas.com>
User-Agent: Thunderbird 2.0.0.12 (X11/20080213)
MIME-Version: 1.0
To: Jiri Kosina <jkosina@suse.cz>
CC: James Bottomley <James.Bottomley@hansenpartnership.com>,
       ksummit-2008-discuss@lists.linux-foundation.org,
       linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-2008-discuss] Request for discussion on when to merge
 drivers
References: <1213802866.3515.24.camel@localhost.localdomain> <4859461A.7060003@panasas.com> <alpine.LNX.1.10.0806190117090.4593@jikos.suse.cz>
In-Reply-To: <alpine.LNX.1.10.0806190117090.4593@jikos.suse.cz>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1784
Lines: 37

On Jun. 19, 2008, 2:20 +0300, Jiri Kosina <jkosina@suse.cz> wrote:
> On Wed, 18 Jun 2008, Benny Halevy wrote:
> 
>> Exposing the not-yet-ready-to-be-released code to linux-next will expose 
>> conflicts earlier, and hopefully in smaller, more manageable deltas.
> 
> I like the way linux-next works now, i.e. it should reflect what is going 
> into the next major kernel release. Nothing more, nothing less.
> 
> Also, when talking about entirely new drivers for hardware that hasn't 
> been supported by the kernel at all so far (this is the situation we are 
> talking about, right?), there shouldn't be a lot of conflicts to be dealt 
> with, right? Ideally, drivers should be pretty isolated standalone pieces 
> of code that don't have any business changing any code that has been 
> already there.
> 

The showcase example I have in mind is our OSD initiator for which
we pushed all dependencies already upstream, so currently it has
no conflicts with the existing code.  However, it is not ready
for the next release since it should be reviewed, documented,
and accepted by the sub-system maintainer first.

I would like it to be included in linux-next so to be alerted of any
arising conflict so I can fix it in "real time" rather than waiting
for the next release to come out.  Initially I thought it'd be a good
candidate for linux-staging, but Greg doesn't quite agree with that
(http://lkml.org/lkml/2008/6/11/225) since it's destined for linux-scsi.
Hence, a -staging branch/tree based off of James' tree makes sense.

Benny

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