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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <485A2341.9020406@s5r6.in-berlin.de>
Date:	Thu, 19 Jun 2008 11:13:37 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	benh@...nel.crashing.org,
	ksummit-2008-discuss@...ts.linux-foundation.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-2008-discuss] Request for discussion on when to merge
 drivers

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/