[i2c] [PATCH] OMAP: I2C driver for TI OMAP boards #2

[David Brownell]

On Monday 31 July 2006 12:25 pm, Jean Delvare wrote:
> > > 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 see ...

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

The only benefit I can forsee for staging this through MM would be
to verify that the kbuild stuff makes no trouble.  It's not like
anyone can use the MM tree for OMAP, any more than they can use
the main kernel.org tree ... until I2C gets merged.  :)

But whatever floats your boat.  I can carry an I2C patch around
for a little while.


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

Well do I know that story!  And let's not forget retesting...

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

Well, you've seen my basic review.  As for "later", it's quite routine;
that's what "submit early and often" means.  That whole ext4 devel
cycle depends on using "later" intelligently.

- Dave