Hi Mauro, On Friday 21 May 2010 17:03:04 Mauro Carvalho Chehab wrote: > Laurent Pinchart wrote: > > 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. Isn't that even worse than what we did for 2.6.34 ? How are developers supposed to test their drivers against changes in the v4l-dvb repository ? By merging all staging branches manually every time ? > >> This new procedure is still experimental, but I think it will be better > >> than the previous one. -- Regards, Laurent Pinchart -- 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
