Laurent Pinchart wrote: > Hi Mauro, > > On Friday 21 May 2010 16:05:29 Mauro Carvalho Chehab wrote: >> Hans Verkuil wrote: >>> I had hoped to get hardware to test it with, but no such luck (yet). But >>> there seems to be no sense in holding these patches back on the >>> off-chance that I can get hardware. >>> >>> Gerard, you mentioned earlier that you actually had a c-qcam. It would be >>> nice if you can test this. >> Pulled, thanks. >> >> I'm now trying a new way of merging patches: I'm creating some topic >> branches, as /staging/<foo>. This is the first merge of the new procedure >> ;) >> >> So, basically, those patches went to /staging/v4l1. >> >> I'll periodically merge the staging patches at devel/for_v42.6.35 branches, >> for patches that I'll send for the current merge window, and at >> devel/for_v2.6.36, for the patches to the next merge window. > > When will they be merged to master ? There's a very good question. The current master branch has a very dirty history, with almost all 2.6.33 and 2.6.34 patches merged twice. I'm not sure yet what would be the better way to handle the master branch. To avoid make things worse, I'm considering to merge back at master only after having the patches merged upstream. > >> This new procedure is still experimental, but I think it will be better >> than the previous one. > -- Cheers, Mauro -- 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
