Message-ID: <485A2341.9020406@s5r6.in-berlin.de>
Date: Thu, 19 Jun 2008 11:13:37 +0200
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
MIME-Version: 1.0
To: James Bottomley <James.Bottomley@HansenPartnership.com>
CC: benh@kernel.crashing.org, 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>	 <1213831894.8011.29.camel@pasglop> <1213832399.3515.109.camel@localhost.localdomain>
In-Reply-To: <1213832399.3515.109.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2229
Lines: 48

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/
--
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/