Hi Greg, I don't care too much about the release version. The change in my opinion can't break anything but will make it easier for adopters to get their initial system setups rolling. However, the release train for 1.3 is about to reach its final destination...
Tobias On 15.01.2012, at 02:28, Greg Logan <[email protected]> wrote: > +1 from me. This change needs clear documentation, but I think overall > it will ease support burdens. Are you targetting 1.3 for this change? > > G > > On 1/13/2012 9:01 AM, Tobias Wunden 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] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
