Hi Juho, On Wednesday 15 October 2008, Juho Vähä-Herttua wrote: > Laurent Pinchart wrote: > > Cons: > > - Installing the uvcvideo driver from the source tree will require > > installation of the v4l core module as well (and possibly other v4l/dvb > > modules you require for the hardware you own and use). > > > > What's your opinion ? Is someone strongly opposed to the switch ? If so > > please state your reasons. All constructive opinions are welcome. > > I'll add to the cons installing and learning yet another version control > system. Also I remember that with some projects they require some new > version of mercurial which is not found from any distribution (in that > case there was no snapshots available), so even looking at the latest > code was a serious pain in the ass (excuse me my expression) and > required compiling the whole version control system from source. I hope > nothing even resembling that experience will come out of the switch.
To be honest, learning yet another version control system is one of the reasons why I'm reluctant to switch over to Mercurial. I would have preferred using a git repository instead. However, I expect most people to be interested in the latest version only. In that case they can easily download a tarball. I might be wrong, but I imagine that most people who will download the uvcvideo sources directly from the repository will, now that the driver has been included in the kernel, just want to try the latest version to get a patch specific to their issue. How many developers checkout a non-head SVN revision or use SVN log or diff commands on the Linux UVC SVN repository ? I'd really like to have statistics on such usage. > Also since I'm in China there's all kinds of blocks and connectivity > problems, can the mercurial repository be checked out over http like the > SVN can? If your only connectivity to the outside world is a proxy, HTTP > is very handy. Very good point. http://www.selenic.com/mercurial/wiki/index.cgi/MajorFeatures states that Mercurial uses "Bandwidth and CPU efficient HTTP and SSH sync protocols" so I guess this won't be an issue. > If not, that is a con as well, the tarballs help with it a bit but you don't > REALLY want to do real work by always downloading a new tarball. Hence my question above about usage of SVN log and diff commands (commit is not an issue as I'm currently the only committer). Do you feel that tarballs are unpractical for the majority of users who just want to try the latest version ? > linux-tv.org that you mentioned seems to be owned by some domain hijackers, > so I guess you mean linuxtv.org? Yes sorry. > If I click the "CVS/Mercurial" link on their page I get an empty page. :) > Not so convincing, but at "Repositories" link I can get links to tarballs. > There's no easy way to get all required tarballs and nothing else, I > really wouldn't list the tarballs as a pro since you have to get many of > them... You only need a single tarball, the one containing the tree you want to checkout (in our case this would be the linux-uvc tree). People complained in the past about the lack of tarball and the required use of SVN so I thought everybody would be happy with tarballs, but it seems this is not the case :-) > So generally I'm opposed to the change, but if that's the only way to > avoid ugly ifdefs around the code then I guess have to say go for it. I'd stick to SVN too if it wasn't for the #ifdef's :-/ > Personally judging by that email, I feel that the barrier to download > and compile uvcvideo will be much higher than before, maybe even over > the limit of doing it on your own. That's just my 5 euro cents (around > 0.47 CNY with current rate). I see two use cases. Developers who require "advanced" VCS features will need to learn Mercurial, but I don't think that will be a huge burden. I also don't think there are many such developers. Users who need to get the latest version at some point will just have to download a tarball. This in itself lowers the barrier. They will also have to compile and install the v4l core modules in addition to the uvcvideo module. That could raise the barrier, but don't forget that there should be more community support as compiling and installing a linuxtv.org tree is an operation performed by more users than compiling and installing the uvcvideo driver. In a quick chat on the #v4l IRC channel I got told v4l developers do not receive much support requests from users who have trouble compiling a linuxtv.org tree. I can't tell from personal experience though. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
