On 13-02-05 01:46 PM, Christopher Brooks wrote: > 1. If we do not have capture agent code that works then we no longer > have an end to end lecture capture solution to provide. Mara used to > use the term "soup to nuts" for this, and I believe it was one of the > strongest aspects of Matterhorn at the time -- there is no open source > project that can claim this. Dropping the capture agent is a bad > strategic decision to me.
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. > 2. If the bugs are all related to installing on new OSes we can just > not support those OSes. This isn't a software bug, it just means more > manual configuration, and thus we have to write documentation. The > capture agent does not have to run on someone's favourite OS, it can run > on an older one without compromising our overall project. We don't > have to kill the dog because it has fleas. Fair enough. I would be for supporting the CA only on 12.04 (for example). This would alleviate the majority of the versioning issues, while simultaneously keeping the CA around. We could also switch to a more stable version of Linux (Debian?), although I'm not sure I'm a huge fan of that much change that quickly. Can we get an estimate of how much work goes into supporting older versions of Ubuntu (and whatever else we're supporting) currently? It would be good to have a general idea before we go much further. > 3. If the issue is hardware we can just change the reference hardware > page to list minimum specs. I'd prefer to see an institution contribute > a known working hardware profile, but if no one wants to do it then > lets just list minimum specs. Any modern hardware other than an atom > (and maybe even that now) can run the CA. This has been a big concern over the long term. We know that there are institutions who have gotten cards working, but I have seen very few contribute that information back into the wiki. > 4. It is inappropriate to point people to a particular vended solution > regardless of whether it is open source or not. Why would other > vendors participate in the Opencast project if we just tell people to > go buy solution X? I'm all for promoting vended solutions, but I am > not for preferring one over another in this fashion. I agree there. I think it was a misstep to point to any given vendor, but I don't think that was the intention of the initial email. G > In short, the vision of Opencast Matterhorn as a community managed > lecture capture and media processing platform is one that, I believe, > must involve a commitment to capturing video. There are ways we can > reduce development time on the CA without killing it off -- reducing > reliance on install scripts and instead providing documentation, not > implementing features that are risky (streaming, confidence monitoring, > etc.), providing testimonials of working hardware configurations as > well as minimum specs instead of a reference platform. > > I hope these issues will be carefully considered before this proposal is > enacted. > > Chris > > On Tue, 5 Feb 2013 10:55:57 -0600 > Greg Logan <greg.lo...@usask.ca> wrote: > >> On 2/5/2013 9:58 AM, Christopher Brooks wrote: >>> None of these are ecl licensed. >>> >>> Why can't there just be many agents? Why don't we just quit >>> determining minimum hardware, and instead just indicate hardware >>> that people have successfully used with the codebase? >> >> There's nothing saying people can't still use the reference, just that >> there's no one on our side ensuring that it's up to date. The issue >> with not determining minimum hardware is that then people will attempt >> to use the CA on underpowered hardware (atom boxes, and mac minis come >> to mind) and then yell at us when it doesn't work because we haven't >> determined the minimum spec. And there has been lots of success with >> other, non-spec hardware, but I have yet to see any of it put into the >> lists we already have on the wiki... >> >>> I don't see a good reason to quit using the reference code and >>> suggest a single vended solution instead. Some are still using the >>> reference code without issue, and while it isn't evolving quickly >>> that isn't preventing the core from evolving. .. >> >> The biggest reason is time. We have a limited pool of developer time >> available, and if those two devs supporting the CA could be better >> spent elsewhere then it doesn't make sense to keep supporting the >> reference CA. >> >> Don't get me wrong, I don't like dropping the reference CA. But I >> also don't like that Adam spends his 20% working on CA bugs related >> to Ubuntu screwing around with package names and removing >> dependencies when he could be working on something that affects more >> of the project. And from talking to people at the unconference, >> there are very very few institutions that even consider the reference >> build when talking about rolling out CAs. >> >> G >> >>> Chris >>> >>> >>> Ruediger Rolf <rr...@uni-osnabrueck.de> wrote: >>> >>> We in Osnabrück have an LGPL licensed alternative too [1], but >>> I did not mention it in this context as we use a different >>> technology stack (Windows) and our project is not complete in >>> features yet (no scheduling i.e.) and not as mature as the >>> Galicaster. >>> >>> And maybe even other open source options may appear in the >>> future? >>> >>> Rüdiger >>> >>> [1] http://zentrum.virtuos.uos.de/therec/# >>> >>> Am 05.02.2013 16:48, schrieb Stuart Phillipson: >>>> >>>> On 5 Feb 2013, at 15:15, Ruediger Rolf <rr...@uni-osnabrueck.de >>>> <mailto:rr...@uni-osnabrueck.de>> wrote: >>>> >>>>> Especially Teltek's Galicaster is an valid alternative to the >>>>> reference Capture Agent as it has an open source license too >>>>> and works on very similar hardware. >>>> >>>> I'd agree with this statement. When we were looking at capture >>>> agents we either wanted an off the self product for simplicity >>>> or something we could customise to our environment. We ended up >>>> going for customisation and Galicaster vs the reference agent >>>> didn't even get off the paper stage. Galicaster was and is >>>> evolving so much more rapidly, it's a bit more user friendly to >>>> noobs and seems to have a much more active community. >>>> >>>> That said I'm wondering how Teltek would feel about being the >>>> only future FOSS offering on the capture agent seen? >>>> >>>> >>>> Stuart Phillipson |* Media Technologies Coordinator* >>>> >>>> Room 1.023 Devonshire House >>>> University of Manchester >>>> Manchester >>>> M13 9PL >>>> United Kingdom >>>> >>>> e-mail: stuart.phillip...@manchester.ac.uk >>>> <mailto:stuart.phillip...@manchester.ac.uk> >>>> Phone: 016130 *60478* >>>> * >>>> * >>>> >>>> >>>> _______________________________________________ >>>> Matterhorn mailing list >>>> Matterhorn@opencastproject.org >>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>>> >>>> >>>> To unsubscribe please email >>>> matterhorn-unsubscr...@opencastproject.org >>>> _______________________________________________ >>> >>> >>> -- >>> >>> ________________________________________________ >>> 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: rr...@uni-osnabrueck.de >>> Internet: www.virtuos.uni-osnabrueck.de >>> >>> ------------------------------------------------------------------------ >>> >>> Matterhorn mailing list >>> Matterhorn@opencastproject.org >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>> >>> >>> To unsubscribe please email >>> matterhorn-unsubscr...@opencastproject.org >>> ------------------------------------------------------------------------ >>> >>> >>> >>> _______________________________________________ >>> Matterhorn mailing list >>> Matterhorn@opencastproject.org >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>> >>> >>> To unsubscribe please email >>> matterhorn-unsubscr...@opencastproject.org >>> _______________________________________________ >>> >> >> > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list Matterhorn@opencastproject.org http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email matterhorn-unsubscr...@opencastproject.org _______________________________________________
