<div dir="ltr">On Sun, Sep 26, 2010 at 09:19:41AM +0800, Sam Spilsbury wrote: >> So I was looking forward to starting my day on a positive note until I >> scroll through the commit logs and see this: >> >> <a href="http://git.compiz.org/compiz/plugins/ezoom/commit/?id=aec55753c2b99764dbad6cd77832f0725b62ddcd" target="_blank">http://git.compiz.org/compiz/plugins/ezoom/commit/?id=aec55753c2b99764dbad6cd77832f0725b62ddcd</a> >> >> Is this seriously how we can expect the project to function? > > I will avoid answering the details to avoid turning this into a > confrontation. The details need to be answered. > I have worked on Compiz for 4 years. I have gotten very little or no > recognition for my work, and I have fought a lonely battle whenever I have > brought up the organizational problems that has riddled Compiz. When > Compiz++ was merged /without/ the documentation I insisted and everyone > else agreed was necessary, I lost what little motivation I had left. Sorry to hear that. > I could not fight yet an other fight alone. I knew that if there was no > documentation posted and a good approach to merging, merging of compiz++ > and/or nomad would mean the death of Compiz. > I was right. You were wrong. Your 'vision of what compiz should be' might be dead but the project is still very much alive and well thanks to the people that have been actively contributing to it. > This summer, I finally decided to pick things up again. My first impression > proved all my fears. Then I picked up eZoom, which had a few severe but > easily fixed bugs. But the biggest problem was that it was not a C++ > plugin. I used to think of it as an example of how I wanted a plugin to > look, but that was far from the case when it was ported to C++. C and C++ > require different approaches, and a simple port only gets it functional. > That is not a critique of the work done to port it, but an acknowledgement > that getting it working is only the first part of porting it. If you want to pick up were you left off, use the compiz-0.8 branch. Do not make major changes to C++ ported code without discussion. > I had to re-learn Compiz. That is no small task, and it has taken me > several months to realize the easiest way to do that. For numerous reasons, > I was not very active during that time period. But I was working on the > parts of Compiz that are struggling hardest - organizational planning. > > We can not continue as we have. Compiz will go on with the developers it always has. We do not have to wait on anyone anymore. > None of the other approaches used in Compiz, Beryl and Compiz Fusion > present a good, lasting way of producing a quality product. This is your opinion, which I disagree with. We don't pay developers to work on compiz so we take any contributed work we can find and make improvements on top of existing work. There's no such thing as perfect and it doesn't make sense to rip out code without asking anyone or discussing the proposal first. > Hacking on eZoom if I hadn't found a solution to the bigger problem seemed > a waste of time at best. > > I still do not have a perfect plan, but I have several small things I want > to try. I do not intend to turn your world up-side-down over the night - > that is the best way to destroy what is left of Compiz - but I will > implement some changes. And I will not always perform a vote. You can't just come in and say 'this is how it will go: we only vote if it is something anyone else is doing except me.' > The key is communication. You say this directly after saying "And I will not always perform a vote." ...? > Ignoring it was not a real alternative. Why not? You have ignored it up until now. > Fixing it would help establish a > culture where "you" write the bugs and "I" fix them. I'd rather avoid them > in the first place and thus help "you" improve the general quality of his > or her code. We can't improve anything if it's not there to improve.. If you are going to take the time to review and make changes to the code, you need to communicate with others about what you think is wrong done and why, and offer suggestions on how they can improve so everyone will know how to make better commits in the future. > Sending a mail would not sufficiently demonstrate how important this is. It > would most likely result in no real changes and me having to fix it myself > or ignore it. Why do you think it is so important? It does not cause any crashes and it's not a major change. It's just a new feature. However, ripping out newly added features *is* a major change. We are expecting to throw around a lot of new features into 0.9 since 0.9.x is all development. In fact, this particular feature is planned to make it's debut in 0.9.2. > The only option I had was to revert the commit.That would force a > discussion and it would demonstrate the importance of not letting buggy > code enter our releases if it can be avoided. That way of thinking is backward. A discussed should have been brought about first before reverting the code. You never even stated what is buggy about the code exactly. I personally tested thoroughly and it works as expected here. > By reverting the commit I am not saying "go away". I am saying that it is > not ready. To make it ready, I suggest posting the patch-set here. I will > not expect all patches to go through our mail list, but I believe the best > development culture we can aim for is one where any not-good code is > reverted and then brought up for discussion by whoever committed it in the > first place. Using the mail list allows everyone to participate. By reverting the commit without question or discussion you're saying 'I will do whatever I want without question', which really creates an unwelcoming shadow over all developers. Also can you explain what you mean by 'not-good' code? Can you explain what is wrong with the code in detail? > The reason is that any other approach would likely lead to bad code being > ignored. If I have to fix it, I will rather ignore it. If I have to start > the mail discussion, I will rather ignore it. History has shown us this. Again, why is the code bad? Also, you did not ignore it. You reverted it. If there was this big of a problem that needed a full commit revert, you should have attempted to contact the author and provided you have contact with them, explain the hows and whys of what they did wrong and how it can be fixed. Now instead working on more important things, I'm spending time responding to this thread trying to figure out what is so wrong with this code that it requires reverting. > This is a way to do peer review. I happen to be the expert on eZoom, and it > is highly related to the fact that I wrote it. But the reason I revert it > is not because I own the plugin, but because I am the expert and I care > greatly about it. When I have re-established my confidence and motivation, > I intend to do the same to core. The goal is good releases and effective > development. While it is understandable to be defensive with your own plugin, it is still not grounds for reverting a new feature without discussion or reason. This is by no means a way to do any form of 'peer review'. And by the statement 'I intend to do the same to core', what exactly do you mean? I do believe the other core developers would be interested to know. > It is not kindness to allow new developers to push code of poor quality. It > is kindness to help them make good code. That is what I wish to establish a > culture for. You haven't explained what is 'poor quality' about it. > As a last little apropos, I would like to remind everyone that it is not > only new developers that require positive feedback to keep them self > motivated. > > - Kristian Reverting commits you feel are not up to your standards without reason or discussion is not positive feedback. At all. To be part of this project means working with everyone and that means not removing others works while acting alone. This incident demonstrates the complete opposite of communication and organization. Unless you're trying to create the ultimate double standard, what you're doing is wrong, backward and a good way to lose any respect you might have from other developers. Compiz isn't a corporation or a company, it's a window manager for the X windowing system and should be treated as such. We are striving to give the end user a good experience while having fun writing it and making it better along the way. This isn't a war, a race or something that anyone needs to get excited about. I like a lot of your ideas Kristian but you're going to have to meet everyone halfway. I am doing my part by posting on this mailing list like you requested. No human is a perfect developer and enforcing such severe restrictions on code will only hinder development and stifle new works. If you want to work with us, you can't just sit back with the scissors and expect everyone to rewrite everything when you push the button. Scott</div>