Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Michael Krufky <mkrufky@xxxxxxxxxxx>]

Alex Deucher wrote:
> On Feb 13, 2008 6:24 PM, Michael Krufky <mkrufky@xxxxxxxxxxx> wrote:
>> On Feb 13, 2008 3:20 PM, Brandon Philips <bphilips@xxxxxxx> wrote:
>>> On 10:24 Tue 05 Feb 2008, Mauro Carvalho Chehab wrote:
>>>> Maybe we've took the wrong direction when we've decided to select
>>>> mercurial. It were better and easier to use, on that time, but the -git
>>>> improvements happened too fast.
>>> We should consider a move to a full-tree git.  Particularly, it would be
>>> nice to be have v4l-dvb merging/building against other subsystems in the
>>> linux-next tree:
>>>
>>>   http://lkml.org/lkml/2008/2/11/512
>>>
>>> Also, it would save the silly pain of things like this meye.h thing and
>>> pulling in fixes from the rest of the community that patches against git
>>> trees.
>>
>> When we moved from CVS to HG, we lost many developers.
>>
>> Of the developers that remain, most of us are finally comfortable
>> working in mercurial.
>>
>> I understand the benefits of moving to git, but that option was on the
>> table when we moved to mercurial from cvs, and it was shot down.
>>
>> I would prefer that we stick with what we have for now -- for the sake
>> of our users / testers, and for the sake of our developers.
>>
>> Lets not drive away more contributors.
>>
>> Additionally, the moment we move development from hg to git, we are
>> bound to the development kernel -- we will no longer be able to work
>> against any stable kernel series, and we will lose all of our testers.
> 
> Why would git have any affect on what kernels you could test against?
> It's just an scm like hg or cvs.

Alex,

You are correct.  However, it is not just the SCM in question right now.

Quoting Brandon Philips, "We should consider a move to a full-tree git"

...he is not suggesting that we simply change SCM's -- rather, he is suggesting that we work within a full kernel tree, using git, just as the other subsystems do.

This model makes sense for kernel development, but this is not exactly kernel development -- it is kernel *driver* development.

We stand to lose too much by moving to this model.

Regards,

Mike

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list