Re: [Ksummit-2008-discuss] Request for discussion on when to merge drivers

[Benny Halevy <bhalevy@panasas.com>]

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