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: 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)
  • Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
    ... kernel has become so big now that review cannot be the only ... If people aren't reviewing, ... There are still classes of drivers. ... use interfaces that are really generic driver interfaces and fairly stable ...
    (Linux-Kernel)
  • Re: 64-bit games?
    ... >"Kroagnon" risked the wrath of Usenet weenies when he ventured forth ... >>> I did see a review of 64bit HL2 that said it was basically no differant ... grab the latest drivers. ...
    (comp.sys.ibm.pc.games.action)
  • Re: Reminder: non-mpsafetty drivers to be *dis*connected on Sunday
    ... I would love to be able to send some patches. ... need some information about how to interface with the MPSAFE TTY ... suggestions to look at patched drivers. ... I'll be happy to work on sionce the code hits the tree. ...
    (freebsd-arch)