[compiz] The future of Compiz

[Sam Spilsbury]

On Fri, Jan 2, 2009 at 4:14 AM, Kristian Lyngstol
<kristian at bohemians.org> wrote:
> On Thu, Jan 01, 2009 at 07:39:56AM +0900, Sam Spilsbury wrote:
>> On Wed, Dec 31, 2008 at 9:09 PM, Kristian Lyngstol
>> <kristian at bohemians.org> wrote:
>> > Where are we going?
> (...)
>> > We've constantly been waiting for something that will change everything,
>> > and whether we call it an object framework, nomad or Compiz++, the reality
>> > is that all these branches are counter-productive, regardless of how fun or
>> > flashy they are.
>>
>> The answer is fairly simple in my opinion. It's that we never agree on
>> anything, so in order to not be covered in flak by the time their
>> hands meet the keyboard, people _have_ to develop projects in quiet if
>> they ever want them to go anywhere. People have limited lives outside
>> of compiz so in order that anything might actually get done, they just
>> skip any potential endless argument and get the job done.
>
> I really don't recognize this scenario. How can we disagree when we don't
> have any real technical discussions? I've spoken to a few of the developers
> in real life and enough on IRC to know that we do, in fact, agree on most
> of the hardcore development points. So what if it took us 100 mails to get
> a name, that's not what we're really talking about. Nor do I believe any
> developers considered that to be a major issue either.

The reason why we never have technical discussions about serious
changes is because many times there will always be disagreement and
flak-throwing. I'm not saying that this is a bad thing, it's just that
certain people (namely me sometimes) take these things a bit far. My
point here is that these endless discussions really go nowhere and
usually one or two people just hijack the situation and take control
as Jeffery pointed out.

>
>> I think this is something we really need to fix as a community. Dennis
>> should have just been able to post a mail to the list saying 'Core is
>> broken,  I have time to work on it, here is a list of features I
>> propose', have minimal discussion, have him present to us a prototype
>> and if it works then we think about merging it. However, I really
>> don't think that would have been possible with the current kind of
>> community we have now. Notice how much of the argument so far has been
>> zealotry about a C++ based core? 'Ohhh, but look what Linus Torvalds
>> said, he called C++ "bullshit"' NOBODY has taken serious notice of the
>> other things compiz++ includes, which do fix some really broken
>> application-wise things about core.
>
> The problem is that all these things were done together. Many of the
> features that Dennis have written are no-brainers when it comes to decide
> whether we want it or not, but C++ is a big step, and gambling everything
> on C++ being accepted and a success is wrong.

Perhaps we need to weigh up the benefits and cons of having a C++
based core. It would be worth asking onestone if many of the features
could be implemented neatly and easily without C++

>
>> > So why do we loose developers? I see a few important reasons:
>> >
>> > - The project has no goals, and essentially all development and design is
>> >  done as a solo race. There's no way to know whether you can work on
>> >  something without loosing your work because some obscure branch gets
>> >  merged.
>>
>> Definitely. To be quite honest, I've abandoned all compiz related
>> stuff for a while to work on something else because I really don't
>> know what the deal is with compiz++. If it gets merged, everything I'm
>> working on will be broken. If it doesn't then I'm fine.
>
> This is exactly what I'm talking about. We can't have a situation where
> this is the general consensus among most developers.
>
>> > - The code is undocumented, specially core, and not particularly pretty.
>> >  Even new code is added using this same style of no documentation and
>> >  functions that do more than C functions should do. This is not something
>> >  new, but even people who realize the problem are ignoring it.
>> >
>>
>> Agreed. New developers need specifications on how core's interfaces
>> work and just saying 'Look at how other plugins do it' is just lazy.
>>
>> As for the messyness and longness of code, I can think of a few
>> example that really need fixing straight away.
>>
>> display.c handleEvent()
>> display.c addDisplay ()
>> screen.c addScreen ()
>> screen.c All output related code should go in output.c
>> window.c addWindow ()
>
> All of these are functions I've been talking about for years. I started
> cleaning this up in Beryl right before the merge, but after the merge, I
> ended up waiting. First for things to settle, then for the object
> framework. That never happened and there was no decision as to what to do,
> and I ended up, like everyone else, in a watch-and-see mode.
>
> We CAN fix this.
>
>> > It is my honest belief that we should focus on these three major problems,
>> > before we do anything. The first step is to decide what to do with the
>> > three branches we have going. And we need to know exactly what benefits and
>> > drawbacks each branch have, how compatible they are and how the authors
>> > envision that they will be maintained.
>> >
>> > This is where the authors/owners of those branches should come together and
>> > start explaining their thoughts about merging and compatibility and
>> > maintainability. If not, we really have no other choice but to consider
>> > those branches forks of Compiz, and move ahead based on master.
>> >
>>
>> Here's a real dillema. We're actually forced to consider compiz++
>> _now_ before anything happens. If we do go ahead and fix Kristian's
>> problems with the project it's going to bring compiz++ out of sync
>> with master and we would have essentially missed a huge window of
>> opportunity again. Unless onestone can maintain compiz++ with compiz
>> master for a while as we sort things out.
>
> What, exactly, would happen?
>
> We're in control of our own project. If anyone wants to merge year-old
> branches today, they will have to explain to everyone what's going on.

It's not practically possible to merge one year old branches,
especially when the codebase for compiz++ deviates quite significantly
to current master.

>
>> If we only concentrate on making compiz stable then we will continue
>> to go down this path where we lose developers to more interesting
>> things. The 'experimental' branch is fundamental to our project,
>> because it adds the 'iz' in 'compiz'. With that kind of thing, that is
>> the way we really attract developers. Compiz is becoming more
>> irrelevant every day without it. When was the last time you saw
>> 'compiz' as a bullet point on a distribution release? When was the
>> last time you saw 'compiz' on the front page of digg?
>
> It is completely possible to have a stable environment without loosing
> innovation. You don't need to put up with undocumented and crappy
> "temporary" code to preserve innovation, but doing so will definitely
> hinder stability and developer motivation.
>

I'm not saying that we shouldn't fix the project, just saying that
without the 'reasearch project' feel to developers, we're bound to
loose interest. Look at how many people have signed onto gnome-shell
and KWin for example.

>> I think that we need to have this kind of turning point now, before
>> it's too late. I'm also signed on to fixing up the project as a whole.
>
> That's really great to hear. I'm also glad to see imnotpc and Quinn take
> part in this, that means that even if people are contributing less, they
> are still interested in the project, and as long as there's interest,
> there's hope.
>
> I really hope Dennis and Danny will comment on this thread ASAP, as they
> are the maintainers of Compiz. It would be nice with input from David too,
> of course, but to be frank, Compiz needs David to detach himself from the
> project so we can move on. It's sad, but it's the reality. Either that, or
> a major change in attitude towards cooperation.
>
> I believe our first course of action is to establish a coding standard for
> Compiz and Compiz core. That's a coding standard that goes far beyond just
> how you name your variables and whether you use tabs or spaces. I'm talking
> about clear guidelines for what we believe is acceptable code in Compiz and
> what's not.
>
> Next I believe we should apply those standards to the branches we have, and
> look at how (un)acceptable they are, specially compared to what we have in
> Compiz master. We also need to look at what the benefits of merging these
> branches are, how they will be maintained over time, and the down sides.
> These branches were obviously started before any such standard was decided,
> but that's no reason not to require them to be updated prior to a merge,
> if not to meet all the points, then at least to meet the majority of them.
>
> After this, we need to decide down to earth goals for our next major
> release. What these goals will be will obviously depend heavily on what
> happens with the branches. I belive we should aim mainly to bring Compiz
> out of a constant research project-like state and into a production
> environment, regardless of what we do with the branches we have.
>
> So who am I to decide what's acceptable and not? Well, I don't see anyone
> else doing it, so I guess that's my cue to take charge. If left unanswered,
> I'll proceed to post my suggestion for coding standards to apply to Compiz
> core in a day or two.
>
> Danny, Dennis.... Jump in any time here.
>
> - Kristian
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJXRX58aD+nxnFLQIRAqdaAJ4kutStl+mRZhqpVKDYyIE2pkDt9QCfd/aE
> NJm3zPgefc1+gdj5zpCSSxw=
> =pJRH
> -----END PGP SIGNATURE-----
>
>



-- 
Sam Spilsbury