Re: New procedures for git - was Re: [GIT PATCHES FOR 2.6.35] Convert bw-qcam and c-qcam to V4L2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux