[compiz] The future of Compiz

[Kristian Lyngstol]

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.

> 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.

> > 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.

> 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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/compiz/attachments/20090101/7acee811/attachment.pgp