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: > > http://git.compiz.org/compiz/plugins/ezoom/commit/?id=aec55753c2b99764dbad6cd77832f0725b62ddcd > > Is this seriously how we can expect the project to function?
I will avoid answering the details to avoid turning this into a confrontation. 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. 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. 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. 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. None of the other approaches used in Compiz, Beryl and Compiz Fusion present a good, lasting way of producing a quality product. 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. The key is communication. Back to the specific revert. I could have done four things: 1. Ignore the commit. 2. Send a mail to sort out the issues. 3. Revert it. 4. Fix it myself. Ignoring it was not a real alternative. 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. 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. 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. 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. 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. 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. 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. 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 Enhanced Zoom MAINTAINER
signature.asc
Description: Digital signature
_______________________________________________ dev mailing list [email protected] http://lists.compiz.org/mailman/listinfo/dev
