Rüdiger, I 100% support your thoughts. We have not been doing a lot of code reviews as of late and we keep running into pitfall after pitfall because if that, so Rubén opening up a code review for the patch in a place that is as central as this one is a good thing. I can also see how he is not happy to get even more work on his plate by having to deal with feedback on a patch that he did not create.
On the other hand you are right, it is about responability for the good of the project, and almost everyone is forced to work on bugs that they didn't introduce for the sake of the project. So I would like to ask Rubén and everyone else to keep a mindset that is about the community and our project as much as your own time. If at some point one feels that things are getting out of hand and overwhelming, he/she is free to ask on list for help or come to the developer meeting and break tasks up into smaller pieces, divide and conquer. That being said, as a committer we agree to spend 20% of our time working on Matterhorn on the good of the community, and those 20% would - at least in my mind - certainly include taking feedback on a patch, incorporate and open it up for review again. Fixing things locally is certainly the worst of all options. Tobias On 09.11.2012, at 09:12, Ruediger Rolf <[email protected]> wrote: > 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 _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
