On Monday 29 June 2009, Karicheri, Muralidharan wrote: > I think you didn't get my point. We have patches that are in > the pipeline waiting for merge that is neither available in > the upstream nor in the DaVinci tree. The linux-media pipeline. Sure. I'm quite familiar with what it means to have pathes depending on others, which are headed upstream by different merge queues. > That gets merged to > upstream at some point in future and also will get rebased > to DaVinci later. But If I need to make patches based on them > (like this one) it can be done only by applying the patches > to the DaVinci tree and then creating new patches based on > that. That is why my note clearly says " Depends on v3 version > of vpfe capture driver patch" Maybe you're not getting my point: that submitting a patch series against mainline (or almost-mainline) means you don't trip across goofs like the one I first noted. That one was pretty obvious. The more subtle problems are harder to see... In this case, your patch ignored a driver that's been in GIT since December. Which means that you're developing against a code base that's ... pretty old, not nearly current enough. I fully understand that all this video stuff is a large and complex chunk of driver code. That's *ALL THE MORE REASON* to be sure you're tracking mainline (or in some cases the DaVinci platform code) very closely when you send patches upstream. Because all kinds of stuff will have changed between six months ago and today. Standard policy is to develop such merge patches with more or less bleeding edge code, so integration issues show up (and get resolved) ASAP. I can't believe the current linux-media or V4L2 trees are six months out of date. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
