Hi, it's good to see that the community is strong. It was very good that Rüdiger brought this topic to list and even better that there were so many responses from the community.
I like the idea and it will solve our problem for now. In the long run, we need somebody who feels resposible for the CA to keep it on track. In my opinion we need the prduct owner back, but with a new role definition. In my perception, we have these persons for most of Matterhorns components/moduls. Not official, but there are a view people who take from a startegic point of view care for the development of the part they feel resposible for. The CA has no person who does this, but needs it to stay in the matterhorn universe (even with the proposed modifications). From my point of view we should bring the product owner back to project. But with a new definition of the role itselfe limiting the effort to a minimum but ensure that we keep all our components on the track. DISCLAIMER: I had no chance to stay at the unconference and due to a workshop I was not able to follow the discussion around it and the report at tuesdays dev meeting. This mail should not jeopardize the results, so delet it, if it does. Nils > Pascal, > > This was something that Adam and Jon and I talked about and came up > with on IRC, so I think there would be folks to help do this. > Ruediger, would this alleviate the issues you see with the CA > development? > > Chris > > On Thu, 7 Feb 2013 21:34:58 +0100 > Per Pascal Grube <[email protected]> wrote: > >> Hi, >> >> as being somebody , I just want to share would I would prefer: >> 1. Keep the Java code. >> 2. Make the Hardware specs more generic. I think something like1 >> Presenter + 1 Presentation you need i3 > 2,5gh, 4gb ram, an hd with > >> 20mb/s datarate. This would imho be sufficient. >> 3. Replace the automatic install script with something manual howto >> setup a CA. >> >> SInce I tried to use the different hardware, that was laying around. >> So I actually took the reference CA more as min specs. This of course >> cause some issues, as I the trickiest part was get the gstreamer >> lines up and running. And at this point the installer did not really >> help me much. >> >> SInce I'm still far from being able to provide code, I would commit >> myself in writing a guide, howto set up basic CA without using an >> automatic installer. >> >> Regards, >> Pascal >> >> On Thursday 07 February 2013 17:54:54 Brooks, Chris wrote: >> > Hi, >> > >> > I'm a bit distressed by the lack of clarity when we talk about the >> > reference agent. There are really three pieces to it: 1. A >> > hardware profile 2. A set of installation and configuration scripts >> > 3. The Java code that does the work >> > >> > >From my perspective, part 1 is old. Part 2 is a pain in the back >> > >to manage, since it involves changing things for new OSes. Part 3 >> > >is, imo, rock solid. I don't know of any failures in our 1000+ >> > >recording setup that have been from something other than hardware, >> > >though I'm not privy to the details and only have discussions on >> > >Adam to go with. >> > That Ben couldn't get a reference agent running does boggle my >> > mind. Galicaster install docs say "install x packages" and "run on >> > an i3 or better". This should work for Matterhorn too if you're >> > using the same hardware, we share the same underlying video >> > processing library, so I am surprised if there is much more than >> > just installing java as well that was needed. >> > >> > When adopters ask for support I say "post to the mailing list, >> > someone there will likely be able to help". What I see you >> > suggesting is saying "go to a different community, we don't' do >> > that". My comments about the player/media processing were not >> > meant as a suggestion but as a comparison; if we axed a player >> > component from Matterhorn I would be similarly distressed. To me, >> > Matterhorn is not just a set of scripts around ffmpeg to process >> > video, but is a novel turn key solution for lecture capture and >> > media distribution in higher education. I think backing away from >> > this stance is a strategic miss-step, and that's why I don't >> > support this proposal. >> > >> > I agree completely with you and Tobias that it is incumbent on >> > institutions who see value in a component to invest in it. That's >> > how it has been with everything. So if the proposal is: 1. Lets >> > get rid of our install scripts, they are too much work and we can >> > just doc things on the wiki 2. Lets get rid of the reference >> > hardware and just list it as something that is known to work >> > >> > I'm all for that. If the proposal is: >> > 1. Lets quit working on the codebase and let it get out of sync >> > with the core >> > >> > I'm against that. We have lots of vendor partners and should >> > celebrate them and make our adopters aware of them (we're looking >> > at them too!). But indicating we're not in the business of >> > producing an open source community-developed lecture capture system >> > is a mistake. >> > >> > I'm also under the impression that others are using the reference >> > code, UCB, UCT along with you and I. But maybe this isn't correct, >> > I wasn't in San Diego where I assume things were discussed in more >> > detail. >> > >> > Regards, >> > >> > Chris >> > >> > >> > ________________________________________ >> > From: [email protected] >> > [[email protected]] on behalf of >> > Ruediger Rolf [[email protected]] Sent: 07 February 2013 10:10 >> > To: Opencast Matterhorn >> > Cc: Matterhorn Users >> > Subject: Re: [Matterhorn-users] [Opencast Matterhorn] Discontinue >> > the Capture Agent? #proposal >> > >> > Hi Chris, >> > >> > I would say that we are even currently in nearly the state that I >> > would expect as an outcome as an official outcome of this proposal. >> > >> > We currently have only very few resources to work on the CA. So it >> > is already stuck in a status where it is nearly unusable for >> > newcomers. And even experienced developers do not know recent >> > hardware where it is working on. >> > Benjamin tried to create a CA with a cheap recent computer that we >> > bought in a computer store close to campus last week. Ubuntu 10.04 >> > does not work on this machine anymore (like on recent Dell models). >> > So we switched to 12.04. The we needed to find a capture card. >> > Again our old reliable Hauppauge PVR 150 are no longer available >> > and even BT878 cards are not easy to get these days, so he decided >> > to use an Hauppauge HVR card that works but has some downsides. >> > >> > I guess that Waldemar and I would have managed to get this setup >> > running with some manual configuration. But even Benjamin as an >> > experience user/dev of Matterhorn failed and decided to use >> > Galicaster instead - with some minor problems too, but at least >> > this worked. >> > >> > In general the current CA works well for USASK and for UOS as we >> > have people who know these devices very good and we have old >> > hardware that is well know to work with the reference CA. But what >> > do you tell adopters that ask you for some support? >> > >> > You suggested to get rid of other Matterhorn components, like the >> > engage player too. I have no problem with this. If the majority of >> > the community starts to use the paella player for example and we >> > don't have the resources to continue the development of the >> > reference engage player, why shouldn't we decide to switch the >> > default player. But at the moment I am willing to put some >> > ressources in the refactoring of the player. And it seemed to me >> > that some other institutions would be willing to do this although. >> > I have not noticed that enough institutions would be willing to >> > invest their money or developers in the reference CA to continue the >> > development. If I am wrong these institutions should speak up now! >> > >> > Jaime and Tobias raised some interesting questions about remote >> > administration, configuration and updates for the CAs, if an >> > institution would really deploy hundrets of them. If we come up >> > with new APIs and protocolls for this. Who will implement this for >> > the reference CA? >> > >> > As we at UOS are seriously investigating other options than the >> > reference CA too, we don't see the need to invest more of our >> > development resources into the reference CA and would focus on other >> > parts of Matterhorn. >> > >> > I see the soup to nuts argument. But I am not sure is this really is >> > that important for a possible adopter. I would expect that that a >> > good installation an usage experience is more important. And from >> > our support for other universities here in germany I would say that >> > with the CentOS repo [1] we have an acceptable experience for the >> > core. But installation, configuration, usage and monitoring of the >> > CA are still pain points - especially for adopters. >> > >> > Rüdiger >> > >> > [1] >> > http://opencast.jira.com/wiki/display/MHTRUNK/Binary+Installation+from+Repo >> > >> > Am 06.02.2013 02:28, schrieb Christopher Brooks: >> > > Hi Olaf, >> > > >> > >>> Keep in mind that we're not planning on deleting the CA code. >> > >>> Just removing the install scripts and explicit support for >> > >>> various hardware bits. There's nothing keeping adopters from >> > >>> using it, the hardware support will still be there. We just >> > >>> won't be testing against any hardware. >> > >> >> > >> Also, I wonder whether you would consider Galicaster a solution >> > >> that still allows us to claim that soup-to-nuts approach. The >> > >> software is OS (ignoring the licence issue here for a moment), >> > >> Teltek supporting its further development and it's not bound to >> > >> HW Teltek is selling, at least I think I remember Stuart saying >> > >> he's running it on his own cobbled device. >> > > >> > > What Greg has written, "...removing the install scripts and >> > > explicit support for various hardware bits..." is very different >> > > from what I perceived in the #proposal from "...bit we will not >> > > really maintain the code in the future so that it will be >> > > outdated in the near future..." >> > > >> > > Regardless though, I don't support the notion that Matterhorn >> > > should not have capture agent software and should rely on other >> > > systems alone. To me, the benefit of Matterhorn was getting rid >> > > of the home built systems we had individually, and coming >> > > together to build an open, community-maintained product that >> > > could scale. I think involving other systems, like vendor >> > > products, is important to creating a viable piece of software, >> > > but I don't think relying on a vendor for a specific portion of >> > > the tool chain is good. >> > > >> > > Also, I don't know anything about the Galicaster system except >> > > what I've read on the website and on this mailing list. >> > > Undoubtedly it is an excellent product, but to throw away robust >> > > community-developed code and instead tell adopters to go to this >> > > vendor for the solution is not something I'm comfortable with. >> > > >> > >> Yes, that was my impression too. I think we've seen what a closer >> > >> alignment with certain vendors can lead to when their support >> > >> isn't there and the price policy is erratic, but I think if one >> > >> could run Galicaster SW on your own device, wouldn't that be >> > >> agnostic enough? >> > > >> > > Why don't we just drop our player and core and instead point >> > > people towards the Kaltura community release (it's open source)? >> > > Open source software isn't just a set of widgets we can replace, >> > > it's about a community that people can participate in. How many >> > > different higher education institutions have commit access to >> > > Galicaster code? How can I contribute back new developments we >> > > make to the broader community, and get their contributions in >> > > return? How can I contribute patches to bugs, and fix problems >> > > when they arise instead of buying a support contract? The answer >> > > is you can't -- it's not a community source project. >> > > >> > > This doesn't have to detract from all the wonderful things that >> > > Galicaster is (free, open source, well supported, python, great >> > > testimonials, etc.). But changing the docs to say "Go download >> > > Galicaster" is cutting away a portion of our product and saying >> > > we're not interested as a community in lecture capture, just >> > > media processing and playback. And I don't think that's true, and >> > > I don't see why that is necessary. >> > > >> > > Chris >> > >> > -- >> > >> > ________________________________________________ >> > Rüdiger Rolf, M.A. >> > Universität Osnabrück - Zentrum virtUOS >> > Heger-Tor-Wall 12, 49069 Osnabrück >> > Telefon: (0541) 969-6511 - Fax: (0541) 969-16511 >> > E-Mail: [email protected] >> > Internet: www.virtuos.uni-osnabrueck.de >> > >> > _______________________________________________ >> > Matterhorn-users mailing list >> > [email protected] >> > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >> > _______________________________________________ >> > Matterhorn-users mailing list >> > [email protected] >> > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >> _______________________________________________ >> Matterhorn-users mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > > -- > Christopher Brooks, PhD > ARIES Laboratory, University of Saskatchewan > > Web: http://www.cs.usask.ca/~cab938 > Phone: 1.306.966.1442 > Mail: Advanced Research in Intelligent Educational Systems Laboratory > Department of Computer Science > University of Saskatchewan > 176 Thorvaldson Building > 110 Science Place > Saskatoon, SK > S7N 5C9 > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
