On 01/11/2012 03:50 PM, Arnd Bergmann : > On Wednesday 11 January 2012, Mauro Carvalho Chehab wrote: >> What I and Guennadi agreed (http://linuxtv.org/irc/v4l/index.php?date=2012-01-05) >> were to do just the reverse: >> >> He would be sending you one single patch with my ack, that would allow the >> arm tree to be merged [1], I would wait for a few days for the arm tree to >> be pulled, and then I would rebase my -next tree to remove that patch >> from it. >> >> [1] http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7 > > It's just not what happened. I got this series from Nicolas: > > 7a1834b ARM: at91: Update struct atmel_nand_data to support PMECC > 9356fba ARM: at91/dma: DMA controller registering with DT support > 31527e7 ARM: at91/dma: remove platform data from DMA controller > 226e3aa ARM: at91: add Atmel ISI and ov2640 support on sam9m10g45 board > e889a64 ARM: at91: add clock selection parameter for at91_add_device_isi() > 7a13e73 media i.MX27 camera: Fix field_count handling. > 166b37f media i.MX27 camera: add support for YUV420 format. > 88c6599 V4L: atmel-isi: add code to enable/disable ISI_MCK clock > ... (the rest of v4l at the time) > > and I merged it into the next/drivers2 branch, explaining that I would > merge these as soon as the dependencies in v4l are merged. :( > >> My -next tree were never meant to be stable. It is just a patch repository >> where I merge from the real development repository, in order to test them >> against the hole changes. From time to time, when bad things happen >> (patch conflicts, compilation breakages, requests to remove bad patches), >> I just rebase it. > > Ok, thanks for the confirmation. > >> I prefer if you could just pick this patch from Guennadi's tree: >> http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7 >> >> and add my ack on it, removing the v4l-dvb merge from yours. >> >> Linus seems to prefer to have the arch trees merged before the drivers >> tree, with makes sense. > > I think it's better for you to just send everything you have right away, > including the atmel-isi patch. > > I'll drop the remaining atmel patches from my next/drivers2 branch and let > Nicolas send me a new rebased pull request for 3.4. The patches in question > look simple enough, but if the developers can't get a simple dependency right > after discussing it for weeks, I'd rather not take it this time. I am so astonished and sad about all this! I have the feeling of having done exactly what Guennadi and Olof had asked me to do: What I get at the end: people having a bad feeling about my work, not expected merge conflicts which annoy everybody (only for a ridiculous amount of code), my patches delayed and a comment saying that I cannot handle simple dependency... Nice result! - Guennadi did not want to take SoC/board code in his tree => I had to take those lines of code through at91/arm-soc breaking the patch series and allowing the introduction of an out-of-sync merge - I built a pull request with only the SoC/board code on top of a Linus' -rc tag (yes, that was breaking compilation on certain configurations in the meantime) => I was told that I should bring the v4l dependency with my branch - I resent a "pull request" on top of v4l branch after a discussion between Guennadi, Olof and me. The conclusion of this discussion was quite obvious: http://article.gmane.org/gmane.linux.ports.arm.kernel/145196 => It was supposed to be the last time I moved those patches around... I have understood and approved all the reasons for the requested changes, of course. But for which gain? Ok... well, it looks like a massive incomprehension which took us time and ends up by wastefulness. Best regards, -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html