+1. I strongly agree. I had originally advocated for the demo capture agent, but I've had change of heart. It convolutes the logs and if gstreamer is installed it triggers unit tests that may or may not work work. For example, our Centos6 distribution came with gstreamer ootb. The presence of gstreamer triggered unit tests that failed because the distro didn't include the proper gstreamer plugins. I had thought our units tests accounted for this but apparently there was a regression. Also ur 3rd party scripts do not include gstreamer (at least that used to be the case) so it is required to install it manually. The installation documentation on our wiki only covers debian although the directions are supposed to apple to all flavors of linux.
On Fri, Jan 13, 2012 at 7:01 AM, Tobias Wunden <[email protected]>wrote: > Hey there, > > (disclaimer: I am aware that I may get some heat with the following > proposal. However, I still think it's valid to give this a little room for > discussion.) > > When shifting views from development to operations, it becomes apparent > that our code setup is targeted at developers, and in principle, there's > nothing wrong with that, especially given that we have been mostly > developing for the past 3 years. However, now that the number of prototype > and pilot installations is starting to grow, all the little things that you > need to keep in mind when you want to do a non-developer setup is hindering > our overall success. > > For this reason, I am going to propose a couple of ideas over the next few > days and weeks, and hope that they will be considered with the goal to ease > adoption, even though it may add a little more setup work for developers > here and there. Overall, a developer will most likely be more patient > setting this up than a potential adopter. > > So here is my first proposal: > > I am proposing to remove the capure agent impl from the default Maven > build profile. The reason is twofold: > > First of all, more and more institutions are buying dedicated Matterhorn > hardware to do their piloting / prototyping. I would much rather add > documentation to the wiki on how to install a fake capture agent than > having to explain to people why in their logs they see a capture agent > (that they did not install) failing to push its capabilities and > complaining about non-existing scheduling data every couple of seconds. > > The second reason is that on many backend machines, there are unit test > failures (e. g. AudioMonitoringConsumerTest) that present a road block for > quite some people on their very first install. > > A Maven profile "capture" already exists, so the change we would make is > to set its "activeByDefault" property to "false", and developers working on > the capture agent would need to change their mvn commandline to include > "-Pcapture". > > I am looking forward to your comments! > > Tobias > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
