compiz - Nov 2014 - Previously, on the Compiz Saga.. Pending Response!

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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/compiz/attachments/20141118/34a60bd3/attachment.html>

On 11/18/2014 10:31 AM, Scott Moreau wrote:
> 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.
> 
> The details need to be answered.
Wow, talk about trying to necro a long-dead thread.  Did I miss a de Lorean fly
by somewhere?

-- 
Stephen M. Webb  <stephen.webb at canonical.com>