linux-kernel - Re: [PATCH] OMAP: I2C driver for TI OMAP boards #2

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20060731212532.810a39f8.khali@linux-fr.org>
Date:	Mon, 31 Jul 2006 21:25:32 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	David Brownell <david-b@...bell.net>
Cc:	Komal Shah <komal_shah802003@...oo.com>, akpm@...l.org,
	gregkh@...e.de, i2c@...sensors.org, imre.deak@...ia.com,
	juha.yrjola@...idboot.com, linux-kernel@...r.kernel.org,
	r-woodruff2@...com, tony@...mide.com
Subject: Re: [PATCH] OMAP: I2C driver for TI OMAP boards #2

> > It doesn't work like this, sorry. The merge window for 2.6.18 is
> > closed. The driver needs to be reviewed before it is merged. So the
> > best you can hope for is -mm soon, and 2.6.19.
> 
> So there's been a change from the "new drivers can be merged late"
> policy?  News to me if so.  Not that this is a particularly new
> driver of course, or at all unstable.

This is my own policy for i2c drivers as the maintainer of the i2c
subsystem. I simply observed that new drivers cause much more late-rc
trouble than all other changes. So in order to let things stabilize
quickly, I don't take new drivers after -rc1. I see no reason why new
drivers would be allowed to bypass the -mm staging anyway.

If people want their drivers merged, they have to send them early. And
if they think I don't review them quickly enough (which is true) they
have to find other reviewers. There is no reason why I would have to
review every new i2c driver. As a matter of fact, I just don't have the
time to do so.

> > Indeed, this is no good. If you want things to improve, please help by
> > reviewing Komal's driver. I think I understand you already commented on
> > it, but I'd like you to really review it, and add a formal approval to
> > it (e.g. Signed-off-by or Acked-by). Then I'll review it for merge.
> 
> Review it again?  I'll try to make some time to help there, but
> it's unlikely I'll notice significant issues that seem to me
> worth holding up the upstream merge.  Certainly none that make
> up for the problems caused by having the kernel.org tree be all
> but unusable for OMAP work, and couldn't be patched later.

The "and could be patched later" way has been tried before, and I'm not
going there again. Later happened to be "never" or at least "too late"
more often than not.

And again maybe other subsystem maintainers have other policies, I
don't really care. I do the things the way I think works better. Anyone
not happy with that will have to help me a lot with the i2c patches
before I listen to him/her.

Thanks,
-- 
Jean Delvare
-
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/