Messages in this thread | | | Date | Thu, 19 Jun 2008 10:34:00 +0300 | From | Benny Halevy <> | Subject | Re: [Ksummit-2008-discuss] Request for discussion on when to merge drivers |
| |
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
| |