Hi,
On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote:
Hans Verkuil wrote:
4) v4l2-apps - I agree that splitting it could be a good idea, provided
that we find
a way to handle the few cases where we have "example" applications at
the media docs.
Note that v4l2-apps also contains libv4l, it so happens that I've been
discussing moving
libv4l to its own git tree with Brandon Philips. Preferably to a place
which also offers
some form of bug tracking. The advantages of having libv4l in its own tree
are:
-it is maintained independent of the hg tree anyways
-it has regular versioned tarbal releases, it would be good to be able to
tag these
inside the used scm, which is hard to do when the scm is shared with
other unrelated
code which does not end up in said tarballs
-this means having a much smaller tree making it easier to clone
-no longer having an often old (stale) libv4l in the master hg repository
(this is partially my fault as I should send pull requests for libv4l
moe often,
but why all this synchronization overhead when its independent anyways)
As said when discussing this with Brandon we were thinking about using
something
like github, as that offers bug tracking too. But I can understand if you
would prefer
to keep libv4l at linuxtv.org .
Hans G.,
I prefer to keep it at linuxtv.org, and together with v4l2-apps. The rationale
is that there are applications that are dependent on libv4l (like v4l2grab).
We're also about to commit a gtk webcam application based on libv4l. So, IMO,
the better is to keep all of those applications together.
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).
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.
(except for bug tracking).
Well, I don't see why not adding a bug tracking system for v4l2-apps an dvb-apps,
if needed. Are you thinking on something specific?
If I can put in wishes I would like bugzilla :)
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 ?
It is a bit of a mix of production code like libv4l and v4l2-ctl, v4l2-dbg.
cx18-ctl and ivtv-ctl, and more test or debug oriented tools. The latter
do not need to be packaged by distros.
Yes.
Personally I would prefer to keep v4l2-apps on linuxtv.org. But the strict
commit procedure that we have for the main v4l-dvb repo can be relaxed
here.
What do you mean by a "relaxed" one? Currently, there's no defined procedure for
the applications there: several different CodingStyles were used on the different
applications and no standard criteria were used to ack/nack changes there.
IMO, we should go on the opposite direction: we need to have some standard rules
also for it (but, it can be more relaxed than what we have in kernel).
Ack, we need to at least have rules, like should build on a modern distro
without issues (if the deps are there), etc.
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.
It may also be useful to define a minimum set of coding style, like how applications
should be indented
So it should be possible for you to have commit rights so you can
use it as your master repository.
Maybe the better owner for v4l2-apps would be Hans G., since most of the changes there
are related to libv4l.
I wouldn't mind giving this a try.
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.).
Regards,
Hans
--
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
