I'm sorry for being rude, but I am quite upset by this, because it has gone too far. I posted a few weeks ago that I was going to be working on zoom over the summer to improve the accessibility, and I have already begun to do that. Every step of the way I have made frequent commits to opencompositing.org and described the progress in my blog. I asked for information about what your (David) plans was, you thanked me for informing me on what I was going to work on and said you'd get back to me. You never did. Now today you commit "11fe37b7673b15e5cbd4be21759311087d9d8694" which introduce major changes to the zoom plugin. You did NOT give a heads up on this, even though you should have known I was working on this. This is simply unacceptable. When you are going to make changes and people have already told you they are working on that code, you have to actually communicate with them, not drop a 1k diff on them. It's not just your time that matters here, but ours too. This is not how people are supposed to co-operate. And also, when you write something, you have to document it. A few lines for each function, explaining what it does. You don't have to explain how or why, just WHAT. This is a common practice that I should NOT have to explain to an experience developer. Please document your changes to the zoom plugin properly so our USERS don't have to choose between two different feature sets when they want to zoom. Because this is about the users, not my pride. -- Regards, Kristian
Kristian Lyngst?l wrote:> I'm sorry for being rude, but I am quite upset by this, because it has > gone too far. > > I posted a few weeks ago that I was going to be working on zoom over > the summer to improve the accessibility, and I have already begun to > do that. Every step of the way I have made frequent commits to > opencompositing.org and described the progress in my blog. > > I asked for information about what your (David) plans was, you thanked > me for informing me on what I was going to work on and said you'd get > back to me. You never did. > > Now today you commit "11fe37b7673b15e5cbd4be21759311087d9d8694" which > introduce major changes to the zoom plugin. You did NOT give a heads > up on this, even though you should have known I was working on this. >To be fair he did mention that he was going to add this functionality months ago, it was also demonstrated at brainshare recently (before your initial email). Also your email (from what I understand) just related to orca integration and input redirection, it didn't seem to have anything to do with todays changes. Also from what I understand, you have forked zoom.c which lost all the git history? If this is the case then you should have branched it so that these changes would be merged. I dont think they impact your changes, do they?> This is simply unacceptable. > > When you are going to make changes and people have already told you > they are working on that code, you have to actually communicate with > them, not drop a 1k diff on them. It's not just your time that matters > here, but ours too. This is not how people are supposed to co-operate. > > And also, when you write something, you have to document it. >The question of documentation was discussed very recently (and before that too). Davids position is that HE is not prepared to spend a lot of time documenting things because there is a good chance his efforts will be wasted if the code changes, personally I'd rather he spent time coding rather than documenting. Someone else could document things. That does not stop anyone from submitting patches to document certain functions which might not be clear. I did exactly that a few weeks ago.> A few lines for each function, explaining what it does. You don't have > to explain how or why, just WHAT. This is a common practice that I > should NOT have to explain to an experience developer. >Its not common developer practice to document each function. Most people do not seem to have much problem understanding whats what, and David is always prepared to answer questions. The documentation is by example at the moment, I have 3 example plugins, the helloworld one is documented as well as I can, and I try to keep it up to date.> Please document your changes to the zoom plugin properly so our USERS > don't have to choose between two different feature sets when they want > to zoom. Because this is about the users, not my pride. >If you understood the original zoom code enough to make an enhanced version of it then it should be easy to understand the new changes, they seem to be reducing code and increasing readability to my untrained eyes.
On Thu, 2007-05-31 at 02:19 +0200, Kristian Lyngst?l wrote:> I'm sorry for being rude, but I am quite upset by this, because it has > gone too far. > > I posted a few weeks ago that I was going to be working on zoom over > the summer to improve the accessibility, and I have already begun to > do that. Every step of the way I have made frequent commits to > opencompositing.org and described the progress in my blog. > > I asked for information about what your (David) plans was, you thanked > me for informing me on what I was going to work on and said you'd get > back to me. You never did. > > Now today you commit "11fe37b7673b15e5cbd4be21759311087d9d8694" which > introduce major changes to the zoom plugin. You did NOT give a heads > up on this, even though you should have known I was working on this. > > This is simply unacceptable. > > When you are going to make changes and people have already told you > they are working on that code, you have to actually communicate with > them, not drop a 1k diff on them. It's not just your time that matters > here, but ours too. This is not how people are supposed to co-operate. > > And also, when you write something, you have to document it. > > A few lines for each function, explaining what it does. You don't have > to explain how or why, just WHAT. This is a common practice that I > should NOT have to explain to an experience developer. > > Please document your changes to the zoom plugin properly so our USERS > don't have to choose between two different feature sets when they want > to zoom. Because this is about the users, not my pride.I never intended my zoom plugin to be "the" zoom plugin. It's just "a" zoom plugin that implements some zoom functionality. I hope that people haven't been under the impression that any zoom functionality that could be written would have to go into my zoom plugin. That's definitely not what I'd like to see. I'd like to see different zoom plugins that implement different zoom functionality. There's no reason the user should have to choose between them, they should be able to use them all at the same time if they want that. I always though that my zoom plugin was useless and more for demo purposes. I wrote a more useful zoom plugin a while ago and I though it made sense to replace the existing zoom plugin with this one, which is what I did yesterday. If someone found the old functionality useful or if you've been able to build something useful from it then I'm happy to see it available as an additional zoom plugin. The things I wanted to get back to you on related to the zoom work you do has very little to do with the implementation of zoom plugins and more to do with how other changes are important to make zoom functionality useful. E.g. changes I'd like to make to the core which will allow applications to incrementally move towards using resolution independent retained mode rendering etc. but I have unfortunately not had time to do that yet. You can ignore my recent changes to the zoom plugin in the fdo repo and keep working on your zoom plugin. I don't want my changes to cause you any unnecessary pain and I'm sorry if they got you upset. -David