On 13-02-07 10:10 AM, Ruediger Rolf wrote: > 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.
I would agree with this statement, but what more do you see changing? Aside from moving the developer time I don't see a lot of changes remaining aside from the decision itself. > 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? It's somewhat of a chicken and egg problem here: We know the old hardware works, but you can't get it anymore. So no one builds the reference CA. Which means that no one is testing with new hardware, so no one knows which pieces of modern kit work! > 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? Lots of that is already there, just unused. Anyone interested should spawn off a new thread and make sure to CC me (since I wrote it the parts that are there). > 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. I disagree, I think it is. But I also think that the adopters look at the system as a whole and don't seem to be terribly interested in building and maintaining their own CAs. I think it's a wash long term: It looks bad that we don't have an official CA, but at the same time it also looks bad when we take a year and a half to get a release out... I keep coming back to the suggestion of reducing support for the CA, but not eliminating it entirely. If we drop everything but a specific version of Ubuntu (or CentOS, or whatever) then we've vastly reduced the amount of testing and support that needs to happen. Looking at my list of tickets relating to the CA (https://opencast.jira.com/secure/IssueNavigator.jspa?pid=10010&component=10010&resolution=-1&resolution=9&reset=true&show=View+%26gt%3B%26gt%3B) I see the vast majority of tickets relating to *recent* versions of the CA are 90+% to do with the install script not working, or confidence monitoring. If we remove the scripts and document things on the wiki instead we could remove the majority of those tickets. Thoughts? G > 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 > >
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 _______________________________________________
