Re: New procedures for git - was Re: [GIT PATCHES FOR 2.6.35] Convert bw-qcam and c-qcam to V4L2
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 ? 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New procedures for git - was Re: [GIT PATCHES FOR 2.6.35] Convert bw-qcam and c-qcam to V4L2
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New procedures for git - was Re: [GIT PATCHES FOR 2.6.35] Convert bw-qcam and c-qcam to V4L2
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
