* David Brownell <david-b@xxxxxxxxxxx> [080918 13:11]: > On Thursday 18 September 2008, Russell King - ARM Linux wrote: > > What I say to Tony: do you want OMAP to be merged into mainline, or > > don't you. If you do, do _not_ accept this patch but get the changes > > already in your tree for omap_wdt.c up to Wim, and then get this patch > > there. Provide the carrot by getting the driver up to date in mainline, > > and the stick by only accepting patches for this driver once they've > > been acked by Wim. Explicitly ask Wim to ack them for you. > > > > Then you have one less driver to worry about constantly being out of > > date with mainline. > > That sounds like a plan. One could go further and work > something like the "stable" tree ... not merging into the > OMAP tree until the patch is merged, or at least queued, > for upstream. Minimal exceptions, if any. (And not for > this watchdog!) > > That should be workable for most drivers; sometimes with > a few arch/arm/plat-omap/include/mach/*.h updates you may > need to ack. Things like CBUS support (no framework for > that is upstream) are cases where it'd fail. > > I'm not exactly in this particular loop except as a gadfly > with relevant insight/background/experience, but I suspect > that a basic goal *MUST* be to avoid having Tony and/or > Russell in the loop unless it's unavoidable. Been offline few days, glad to see the watchdog updates moving forward :) Yes I agree we should deal with drivers directly on the appropriate mailing lists. And then have them fall downstream to l-o tree. We can use l-o tree for testing and integration, but let's add a new rule like Russell is suggesting: Let's get at least an ack from the appropriate maintainer before we apply the patches into l-o tree. And of course we've already moved quite a bit of the driver development to the right mailing lists like USB (except ehci-hcd, grr) and audio. Cheers, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
