No worries, Rüdiger. I'm just upset with this whole situation, and with the whole misunderstanding. I admit I'm a little frustrated, but as "passionate" as I may seem, I did not take it personal. I'm so sorry if you felt offended by my comments. I was just trying to explain my point of view but I guess I got a bit carried away. Besides I'm glad to see I'm not the only one concerned about the backwards compatibility issue. After all, I think our opinions are not so different. For instance, I completely agree with your statement that "devs should go through the whole QA process with their code". That was my point from the beginning.
Anyway, I anyone have felt offended by my comments, please accept my apologies. Rubén Pérez TELTEK Video Research www.teltek.es 2012/11/9 Ruediger Rolf <[email protected]> > No offense Ruben, but I guess you did not get my point. I'm kind of sad > that you have taken my comments that personal and seem to feel that much > offended. > > > Anyway, next time I'll mind my own business and fix the issue locally. > The last thing I want is starting a fight about something that is already > working. > > > This is what I want least. We are all commiters in an open source project > and we have to take responsibilities in this project. If we see that > something is broken and we think that we are able to fix this we have taken > the responsibility to do this. And doing code reviews and reacting on > comments there is something that we as commiters have commited ourselfs to. > > You are completly right: we lack support to backwards compatibility. That > is unfortunate. And I welcome any improvement that increases this. > But just in general (not for this particular issue) who should improve a > patch that is not completly finished yet? I fear that ideas about paid > membership models for Matterhorn will look much more promissing if we see > that devs are not willing to go through the whole QA process with their > code. The we will need a large paid bugfixing and QA staff. And I would > hope that the community will stay strong enough that we don't need these > memberships. > > Rüdiger > > Am 08.11.2012 11:54, schrieb Rubén Pérez: > > Rüdiger, > > I'm all +1 to the namespace change, and I voted as such in the relevant > thread. I'm not complaining about improving this part of Matterhorn, which > was certainly necessary. > > That being said: since the project started we have been unable to keep > backwards compatibility between Matterhorn version. I'm not talking about > external products or vendors. I'm talking that there is no upgrade path > from 1.0 to 1.1, from 1.1 to 1.2 and from 1.2 to 1.3. The only way to > upgrade was basically start from scratch and ingest everything again. That > is really worrying, specially when we talk about a system that can > potentially handle Terabytes of information. I know no other piece of > software where you cannot keep your data between versions, or that does not > provide an automated way of converting your data. Fortunately, the inmense > amount of little glitches and bugs that Matterhorn used to have (and still > has, to some extent) made it unsuitable for a real, large-scale production > system, without a good amount of hard work. This is luckily changing, but > until 1.2 it was unsanely difficult to keep a stable production system with > a reasonable amount of recordings being ingested everyday. > > For the record, we've got 1.2 in the UVigo and we are still here because > we are afraid of what it will take to move all the current recordings to a > 1.3 or 1.4 system. It would mean about one week, 24/7 processing time to > take all the video sources and reprocess again with the qualities they are > now published. It's not something that we can afford in the long run. > > The namespace case is just another facet of the same problem. You've got > your 1.3 CAs that produce 1.3 MediaPackages and you want to ingest them in > a 1.4 core. You simply can't. *I'm talking about official Matterhorn > products, not vendors.* We are basically saying the adopters "I don't > care what you want, you have to upgrade your CAs too". And i wouldn't make > such a fuss about this if upgrading a CA meant nothing, but it does. We are > everyday seeing reports that the confidence monitoring is broken in the 1.4 > CAs, that the VGA support is completely broken (and not just because the > Kangaroo Patch was removed), and who-knows-what more small issues and > glitches that we have made our adopters to get accostumed to, and don't > show up in the list anymore. So, to sum up, we are forcing our adopters to > choose between a buggy CA or nothing at all. Or forcing them to patch the > code themselves, as Rute did, because we didn't give them an alternative. > > Galicaster does support the new namespaces --we were going to wait for > the 1.4 release, but after some users requested it, we were about to > release a maintenance version was to be released by the end of this week > which fixed the problem. Be it as it may, I'm so sorry that someone who I > appreciate as a colleage may think that all this complaining is because I > want somebody else to do my job. I haven't mentioned Galicaster not even > once, and, in fact, if I were viewing this question from a vendor's > perspective, I would have never said a word about namespaces. Quite the > contrary, I would release my maintenance version that fixes the namespace > issue and never worry about submitting the patch, and then I could say that > *my product is more compatible with Matterhorn than the official Capture > Agent.* How lame does that sound, that our own agent can't work with our > own core, but someone else's can? And the saddest part of this, what really > gets me on my nerves, is that it seems that *we don't care at all*. > > Anyway, next time I'll mind my own business and fix the issue locally. > The last thing I want is starting a fight about something that is already > working. > > Rubén Pérez > TELTEK Video Research > www.teltek.es > > > > 2012/11/7 Ruediger Rolf <[email protected]> > >> Hi Ruben, >> >> I'm a little confused. We all know that the update of the namespaces was >> a notworthy change that had several implications. But nobody was against >> the proposal for this update, as far as I remember. >> This current issue seems to me that the Galicaster that is not maintained >> by the Opencast community but Teltek and some other people that are >> interested in it is not compatible with MH 1.4 anymore because of the >> namespace changes. (again: correct me if I'm wrong, I did not follow this >> issue to much). And now you and some other people try to provide a >> backwards compatibility patch, to make a vendor CA compatible to the >> upcomming release, which is probably a good idea. >> >> But who other than you or somebody else assosciated Teltek should provide >> this patch? You are not fixing a bug, you want to increase the >> compatibility of your device. If you want to achive this you have to spend >> as much time on this issue as it takes, you cannot expect that somebody >> else is interested in fixing this problem. At least we in Osnabrück do not >> care about this and Entwine probably not too. >> >> Just my 2ct >> Rüdiger >> >> Am 07.11.2012 19:03, schrieb Rubén Pérez: >> >> As pointed out by Tobias and Christoph, I added a new patch to the trunk. >> Please take a look at it (URL reminder: >> http://opencast.jira.com/source/cru/CR-MH-490). >> >> I'm not willing to commit more fixes or dedicate more time to an issue >> I didn't cause. If this patch doesn't work, or doesn't meet the standards, >> please feel free to commit a new version. >> >> Rubén Pérez >> TELTEK Video Research >> www.teltek.es >> >> >> >> 2012/11/6 Rubén Pérez <[email protected]> >> >>> As discussed in the meeting, I've added Rute's patch to the trunk. You >>> can see the relevant ticket here: >>> http://opencast.jira.com/browse/MH-9256. >>> >>> The corresponding review is here: >>> http://opencast.jira.com/source/cru/CR-MH-490 . Please feel free to >>> join and test the patch, and comment whatever you don't like. >>> >>> Best regards >>> >>> Rubén Pérez >>> TELTEK Video Research >>> www.teltek.es >>> >>> >>> >>> 2012/11/6 Rute Santos <[email protected]> >>> >>>> Hi James, >>>> >>>> We had a similar problem when the NCast pr720 was not sending the >>>> namespace and we put a temporary workaround in place (Ncast has now fixed >>>> it). You are welcome to try it with Galicaster, but I am not sure if it >>>> will work... It's in IngestServiceImpl.java: >>>> >>>> @@ -313,7 +325,17 @@ >>>> InputStream manifestStream = null; >>>> try { >>>> manifestStream = manifest.toURI().toURL().openStream(); >>>> - mp = builder.loadFromXml(manifestStream); >>>> + // Hack for ncast BEGIN >>>> + StringBuffer manifestXml = new StringBuffer(new >>>> Scanner(manifestStream).useDelimiter("\\A").next()); >>>> + if (manifestXml.indexOf("xmlns=") == -1) { >>>> + int pos = manifestXml.indexOf("<mediapackage"); >>>> + if (pos > -1) { >>>> + manifestXml = manifestXml.insert(pos + 14, "xmlns=\" >>>> http://mediapackage.opencastproject.org\"; "); >>>> + } >>>> + } >>>> + mp = builder.loadFromXml(manifestXml.toString()); >>>> + // mp = builder.loadFromXml(manifestStream); >>>> + // Hack for ncast END >>>> } finally { >>>> IOUtils.closeQuietly(manifestStream); >>>> } >>>> >>>> >>>> Thanks, >>>> >>>> Rute >>>> >>>> >>>> >>>> On 11/6/2012 9:42 AM, James S Perrin wrote: >>>> >>>>> Hi Greg, >>>>> >>>>> On 06/11/2012 14:22, Greg Logan wrote: >>>>> >>>>>> On 12-11-06 08:21 AM, James S Perrin wrote: >>>>>> >>>>>>> Hi, >>>>>>> Does anyone have Galicaster (1.2.1) working with MH1.4/Trunk? >>>>>>> We are >>>>>>> able to schedule recordings and they are captured on the CA (VGA test >>>>>>> with white noise) but when the (default) workflow has finished there >>>>>>> is >>>>>>> nothing to see or hear. The Operations show that capture has has been >>>>>>> skipped, but ingest and rest of the operations all succeeded - though >>>>>>> they report no tracks found in the log. >>>>>>> >>>>>>> Same CA works with 1.3 so it could be our inexperience setting >>>>>>> up MH >>>>>>> that is the problem. >>>>>>> >>>>>> >>>>>> While I'm not familiar with the way Galicaster does its ingest, we did >>>>>> change the XML namespaces on the mediapackages in 1.4. Your symptoms >>>>>> exactly match what happens when an older mediapackage is ingested >>>>>> into a >>>>>> 1.4 core, so I suspect that's what's going on. We've discussed this a >>>>>> couple of times in the dev meetings, but we haven't come up with a >>>>>> proposal to handle this case yet. It's simple to fix (I do it with a >>>>>> one line sed script in my study system), just a matter of someone >>>>>> writing up the namespace mangling that's needed! >>>>>> >>>>> >>>>> It probably went over my head at the time, still so much too learn. >>>>> Gives us a starting point even of we just fudge Galicaster for now. Is >>>>> there an issue for this I can't find one? >>>>> >>>>> Thanks, >>>>> James >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Matterhorn mailing list >>>> [email protected] >>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>>> >>>> >>>> To unsubscribe please email >>>> [email protected] >>>> _______________________________________________ >>>> >>> >>> >> >> >> _______________________________________________ >> Matterhorn mailing >> [email protected]http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please [email protected] >> _______________________________________________ >> >> >> >> -- >> >> ________________________________________________ >> 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 mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected] >> _______________________________________________ >> > > > > _______________________________________________ > Matterhorn mailing > [email protected]http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please [email protected] > _______________________________________________ > > > > -- > > ________________________________________________ > 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 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] _______________________________________________
