On Tue, Nov 9, 2010 at 7:58 PM, Greg KH <greg@xxxxxxxxx> wrote: > If it is easy to revert and push later, then the "revert just this > piece" should be done now. > > Seriously, I'm getting very confused here, and am very annoyed by the > whole thing. With good reason. > Here's what I don't like: > Â- the original driver didn't even seem to work properly It _was_ working properly, when it was a separate branch, but the merge to staging wasn't done correctly, so it has never worked there. > Â- people sent me patches they never tested and broke things even worse Part of the blame goes to TI. Even if you have the hardware, it's not straightforward to test this. I have struggled to improve the situation on user-space with the gst-dsp and dsp-tools projects, which btw have not received support from TI, but apparently they were not used to test this (neither was the "official" solution from TI which is much harder to set up). > Â- some people have no respect for the omap maintainers and what they > Â Âthink about things, or even basic knowledge of the kernel > Â Âdevelopment cycle. I don't think this is the case. The opinion of the OMAP maintainers is valuable in order to cleanup the mess that is this driver. But _first_ it has to work. Most people are not developers, they just want to use this driver. > Â- I do not have this hardware so I can't test anything. > > So, from now on, I'm not taking ANYONES patches for this driver unless > it gets an ack from the driver maintainer, Omar Luna. > > Actually, no, I'm not going to take any patch unless it _comes from_ > Omar. ÂOmar, please work to queue up patches and test them, and then > send them to me for merging. > > Any questions? You mean after this pull, or should Omar re-send this pull request? -- Felipe Contreras -- 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
