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

[Stefan Richter]

James Bottomley wrote:
> On Thu, 2008-06-19 at 09:31 +1000, Benjamin Herrenschmidt wrote:
>> linux-next should, imho, exclusively be for things we are pretty much
>> commited to merge in the next release. ie, a staging place to fixup
>> things like build breakages, patch conflicts, etc...
>> 
>> Or else, it will just be another -mm ....
> 
> Well, as Greg said for his driver staging tree, I think we can elide
> this requirement for new drivers.  The good thing about drivers is that
> there's nothing we're really doing to break anything: before the driver
> the hardware was just plane unusable with Linux after the driver well,
> we're hoping it might be ...

This requires that the staged driver does not contain build bugs on any
architecture.

Besides, the definition of what we published in -next so far was:

    Everything in -next is *merge-ready* now (from a subsystem
    maintainer's POV).  The only reason that it is not merged yet
    is that Linus doesn't have a merge window open right now.

And the goal of -next was to check for potential integration problems
that cannot be detected in a maintainer's tree.

So IMO the question is not whether to put stuff which is not ready to be
merged into -next.  It shouldn't, IMO.  The questions rather are:
  - What are criteria for merge-readiness of drivers?
    (When do we have to / are we able to address issues like CamelCase
    names or use of obsolete APIs --- before or after merge?)
  - How to publish drivers which are not yet merge-ready but should get
    into the hands of testers?

IMO the answer to the latter question is still not -next, because the
testing that -next gets is (from what I understood) also with the
specific goal to detect potential integration problems.  Remember, you
publish code in -next of which you can say:  This is ready for mainline,
except that there is little experience yet WRT potential integration issues.
-- 
Stefan Richter
-=====-==--- -==- =--==
http://arcgraph.de/sr/