Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab <mchehab@infradead.org>]

Brandon Philips wrote:
> On 19:50 Wed 20 Jan 2010, Hans de Goede wrote:
>> On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote:
>>> As we're discussing about having a separate tree for v4l2-apps,
>>> maybe the better is to port it to -git (in a way that we can
>>> preserve the log history).
> 
> I have a small script I used to convert the history of libv4l to
> git. Let me know when we are ready to drop them from the hg tree and I
> can do the conversion and post the result for review.
> 
> This is the result from the script for just libv4l:
>  http://ifup.org/git/?p=libv4l.git;a=summary

Seems fine, but we need to import the entire v4l2-apps.

> Also, I suggest we call the repo v4lutils? In the spirit of usbutils,
> pciutils, etc.

Hmm... as dvb package is called as dvb-utils, it seems more logical to call it
v4l2-utils, but v4l2utils would equally work.

IMO, the better is to use v4l2 instead of just v4l, to avoid causing any
mess with the old v4l applications provided with xawtv.
> 
>> Having a separate tree for v4l2-apps would work for me. If possible
>> with direct commit / push rights, given that I'm doing 90% of the
>> libv4l work.
> 
> I am fine with Hans doing this. Thanks Hans.

Ok.
> 
>>>> We would need to do
>>>> some rearranging in the directory structure of v4l2-apps, though.
>>> Yes. Maybe we can move the tools that aren't meant to be used on distros on a separate
>>> dir, like contrib, having a separate make install for building them.
>>>
>>> Also, we need to use some config tool like autoconf that will seek
>>> for dependencies and or require the needed ones or not compile the
>>> applications that depends on some library.
>>>
>> Ugh, I'm no fan of autoconf, but I can see this being handy, any volunteers for
>> doing this bit ?
> 
> I started getting libv4l converted to autoconf earlier. If you are OK
> with it I can provide patches after we get the repo converted.

Seems good enough for me.

>>> For sure, one rule we need to define is what criteria will be used
>>> to classify an application as something that will be
>>> compiled/installed by default, and what applications are
>>> development-oriented applications. On some cases, this is clear
>>> (for example, the API compliance test applications are
>>> developer-oriented, while libv4l is a standard user-oriented
>>> one). However, a debug application (like v4l2-dbg) is a development
>>> application, but it may be nice to have it available at the
>>> distros, to help users to help check/report problems).
>> Ack, I too think having v4l2-dbg available to end users could come
>> in very handy to remote debug stuff.
> 
> Indeed. Any tools that allow us to get insight would be great. Our
> current debugging tool belt is pretty poor in a lot of cases: lsusb,
> lspci, dmesg, "does cheese work"?
> 
>>> It may also be useful to define a minimum set of coding style, like
>>> how applications should be indented
> 
> Adopting Documentation/CodingStyle from the kernel with a few tweaks
> should work. That way we could use existing infrastructure like
> checkpatch.pl to check incoming stuff out.

Yes, but, as we have also non-c code, some rules there don't apply.
For example the rationale for not using // comments don't apply to c++, 
since it is there since the first definition.

> Shall we just go through and convert everything at once then? Bulk
> coding style conversions with cstyle, etc never works 100% and so
> someone will need to review the diffs by hand. Volunteers with
> experience doing that?

I have no strong opinion if we should or not convert the code to some
codingstyle, but, if we do, the better is to do everything at once.

>>> On the experiences we had with v4l-dvb tree, it is not a good idea
>>> to allow multiple people to commit at the master repository, since,
>>> when a conflict rises between two different developers, this can
>>> cause lots of heat. Also, it is easy to corrupt a tree, as a push
>>> with -f flag can remove (or hide, on -git) the objects inserted by
>>> someone else.
>>>
>> I've different experience in the projects with git I've used, as
>> long as there are some governance rules (like never ever push -f,
>> always do a rebase fix your stuff and then push, and if something
>> else got in in the window in between rebase again, etc.).
> 
> If the group of people with commit access is small (3-4) it generally
> works well.

Yes. The more people touching at the same tree, the more troubles may happen.

I don't object to allow a limited group of people accessing it, although
I suspect that, if we open to more than one, we will have more than 4 people
interested on it.

Cheers,
Mauro.