Tobias, Just to clarify, and please bear in mind I don't wish to add more controversy to this, my complaint is not about taking feedback from two fellow developers; I certainly welcome that or otherwise I wouldn't have created the review in the first place. My complaint was about we have identified an issue which we had the solution for, but no one was willing to commit a patch for it. It was not about time or difficulty, it was about will, and we were williingly refusing to make our system backwards compatible. Despite of what I said, I 100% agree with the sentence "Fixing things locally is certainly the worst of all options", but that's exactly what we were forcing adopters like Rute Santos to do. I'm sorry if I find that unnerving, but that's how it is.
As I already said, I got carried away in that email and I said some things I didn't feel, out of frustration. I know that's not an excuse, and I apologize for my harsh words. Please dismiss that last remark about "fixing things locally" because I didn't really feel it, and rest assured that whenever I know how to fix or improve any part of the codebase, I'll always make that available to the community. At least, that's what I've always tried to do since I joined Opencast and, despite the words I said before (which I deeply regret), I'm not planning to change that. Best regards Rubén Pérez TELTEK Video Research www.teltek.es 2012/11/9 Tobias Wunden <[email protected]> > 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] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
