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 Also, I suggest we call the repo v4lutils? In the spirit of usbutils, pciutils, etc. > 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. > >>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. > >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. 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? > >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. Cheers, Brandon -- 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
