Laurent Pinchart wrote: > 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 ? You can merge from devel/for_v42.6.35, where all the staging repositories will be merged. The main difference is that I won't merge the "temporary" hashes at master (as patches might be rebased when sending upstream, generating a new hash). I'm considering also to have a v2.6.34+devel branch with 2.6.34 + all staging branches, to help people to test the drivers using git. > >>>> 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
