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

Relevant Pages

  • Re: [PATCH 3/5] watchdog: cleanup a bit omap_wdt.c
    ... Device drivers don't have such luxuries. ... Not part of this patch series. ... Review rarely happens all at once, unless very few people look at ... for weeks on end until it's nice and shiney, and then submit it upstream. ...
    (Linux-Kernel)
  • Re: [patch 00/54] [Announce] Microsoft Hyper-V drivers for Linux
    ... >> I'm happy to announce, that after many months of discussions, Microsoft ... >> has released their Hyper-V Linux drivers under the GPLv2. ... for some reason my scripts to send patches out caused them to get ... The code still needs lots of cleanup, and review, as is evident by the ...
    (Linux-Kernel)
  • Re: [PATCH 0/18] linux infrared remote control drivers
    ... These drivers have long lived ... Patches are against 2.6.27-rc5-git9 or so, and have been tested running ... That way review ...
    (Linux-Kernel)
  • Re: MSI launches Dolby DTS enabled motherboard
    ... >> This oughtta be good for those of you looking for a high performance + ... >> 7.1 DTS encoding solution: MSI have this neat looking mobo, ... >often fall short with the drivers. ... I did track down one review on DriverHeaven (though it's mostly ...
    (microsoft.public.windowsmedia.encoder)
  • Re: atheros chips dangerous?
    ... persons, whilst with open source drivers the code can be reviewed by all people with enough knowledge about the subject and since peer review is an important concept in FOSS quality it would be desirable to have free code. ... Something worth observing here is that many modern device drivers, especially more complex cards with significant offload of functionality to the card, have closed source components -- the firmware for the device. ...
    (FreeBSD-Security)