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. _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz