compiz - Jan 2009 - Minutes of the Compiz Conference Call, 2009-01-21

Greetings everyone,

Here are the minutes of the very first Compiz Conference Call, which took place
today 2009-01-21. This was a combined IRC & phone meeting, huge thanks to
Novell
and Michael Meeks for setting up the conference call.
The next Conference Call will take place on 2009-01-28.

Feel free to comment these minutes and ask questions to be sorted out during the
next meeting.

Conference Call 2009-01-21
=========================
Nomad
-----
http://en.opensuse.org/Nomad

What's Nomad
~~~~~~~~~~~
Compiz = one of the pieces needed to support Nomad
David created a proxy X server (xdmx) doing forwarding work to other X servers ;
xdmx is made to support all the new extensions, most importantly the Composite
extension, allowing the desktop that is connected to the proxy to be composited,
which is where Compiz becomes involved in Nomad

Nomad is better than current remote desktop solutions ; it allows to have a
fully composited desktop proxied to a toplevel window on another machine

Nomad & Compiz
~~~~~~~~~~~~~
See "nomad" branch of Compiz, which contains all the work David has
been doing
to make this work

Infrastructure summary :
remote desktop, does no rendering <= instance of compiz on the remote side
<=> instance of compiz on the local side => local desktop
This infrastructure allows remote window management

What's needed : a nomad aware version of compiz running on the proxy
(i.e. Compiz is needed on both ends, there's some communication being done
between the instances of compiz to ensure everything works well ; there's
more
than just remote desktop being done, there's also window management that can
be
done locally => window management will always be responsive, no matter how
well
performs the link between the local & remote sides)
It'll will eventualy support OpenGL and GLX, but doesn't yet

< onestone> david_r: why not start a second instance of compiz that
handles
            the toplevel window as root, without such a big change
=> the current Nomad stuff is more efficient and uses less ressources, though
Dennis' proposal would be possible as well
There's basically no overhead in the remote desktop in the current Nomad
implementation

pro's for Nomad :
* improving the remote desktop experience by improving performance and
  smoothness, and enabling remotely enjoying the usual bling
* applications won't notice anything

Side-effect of Nomad branch : cleans up the rendering core, and generalises it
to hierarchies of windows, instead of a single level list.
(moves (glx) rendering out of core to plugins side) [~=> like in Compiz++]

Questions about Nomad:
~~~~~~~~~~~~~~~~~~~~~
Q: how should a missing compiz on the local side be handled ?
    [Lost-in-the-talk question]

Q: can a core interface be added for walking windows instead of having to
duplicate code across plugins (especially paint functions?)
    - code is shared, and existing plugins don't require substantial re-work

Q: surely this is only useful for remote desktop ?
    extremely useful even in the local case, when combined with virtualisation
    David heavily using it for this, backup, rollback, sync etc. all without
    loosing X / application state, or responsiveness.

Q. how does this relate to compiz-HEAD ?
    David would like to get this up-stream into HEAD, certain amount of
    audit work needed for each plugin.

Q. what protocols are supported ?
    Tweaked rdesktop, tunnelling X over RDP, and proxy can fall-back to
    rendering RDP commands instead [ for lame-ass Windows connectivity
    without compositing ]
    Free-software guys just use the compiz / X11 specific channel, and
    ~none of this is in compiz itself ?

Q: what about the changes here:
http://cgit.freedesktop.org/xorg/app/compiz/commit/?h=nomad-0.7.8&id=dbe3817cc78dbae883ae9d51f81ae62f5747789a
    Instead of having just one list of windows, we have a full hierarchy
    So each window, can contain another list of windows.
    Compiz has a lot of places, that used to walk the complete list of
    windows and do something for every one of them. Now we need to walk the
    complete tree.
    Lots of plugins keep working without applying affects to non-toplevel
windows (?)
    [ these effects might not always work on remote desktop ].
    Fade plugin was updated to support Nomad - with this patch, and ~nothing
    more.

Q: what happens to object framework in case Nomad gets merged to head ?
    object framework, initially designed to help make Nomad easier to do
    those changes, affect way more plugins, than the final version we see now
    current design tries to break as few plugins as possible,
    that turned out far better than the huge re-architecting.
    even doing this, cleaned up a lot of things in the core.
    The object-framework work - lots of good stuff:
        + way too much work to get it merged
        + though lots of stuff in there that makes sense
        + at some stage, pull bits in from there,
        + but ~impossible to get it all in in one go.
        + do we really want to do that ?

About maintainership
--------------------
David doesn't have much time for Compiz general work, Nomads requires a lot
of
time to get everything working perfect

Communication
-------------
There's a real problem, mailing lists aren't efficient there, lack of
immediate
response.
=> a solution to setup a better communication is needed
Conference calls ? IRC meetings ?
Combined IRC + phone meetings seem to be the solution
Frequency : weekly
Timing : 14:00 GMT (seems to fit most)

Agenda for the next meeting
---------------------------
Next week : Management, directions, Compiz++, feedback on Nomad
Urgent topic : fixing the Compiz vs Compiz Fusion confusion [trackers, mls]
Possible topics : real merger, would solve the confusion

-----------------------------------------------------------------

Best regards,
Guillaume "iXce" Seguin
-------------- 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/20090121/f3551ca2/attachment.pgp

Ok, first let me explain why I've been absent for two weeks. First my
PSU killed my computer, then I really struggled to find the motivation
to pick this up. It's that hard to work with. But I have spent too
much time and love working on Compiz and Beryl to let this die.

I saw the notes for the conference call, and it looks like it was
mostly just a rush to get as much information out of a man that is
incapable of using e-mail before he disappeared again. That's just too
sad.

The reality is that David has done tremendous amount of work for
Compiz, no-one, not even I, can deny that. However, he has been one of
the worst kind of project leaders we could've had.

Since the merge, David has held control over Compiz and let it grow
stale. Yes, there have been improvements, like Michael points out, but
they have been mostly bugfixes, while the major design flaws have been
left untouched.

Nobody, myself included, wanted to work on Compiz (the core). I was
working on it constantly in Beryl, so why didn't I continue to do that
after the merge? I've been telling myself that it was because I was
opposed to the merge, but that's not really true.

The truth is that I didn't dare. I didn't know when David was going to
announce or release the Next Big Thing, or how he wanted to move
forward. Nobody did.

So now that I cry out about this, someone drags David back into it.
And Novell. I know that the intent was nothing but good, but it was
wrong nevertheless. Compiz has had big community issues, and much of
that is associated with David, and because of that, Novell. Compiz HAS
to be a project that is run by the developers and the community, not
by David, who has never been able to communicate and definitely not by
Novell, regardless of how good the intentions are. We've already tried
it that way, and the most important thing we can do, is make sure that
we have control, and that it doesn't lay in the hands of someone who
can't work the community.

And nomad isn't really an issue yet. Even if we merge nomad now, and
everything is perfect, we will still haven't developed as a community,
instead, we're still being strangled.

I suggest that if David, Novell or anyone else wants to get Nomad
accepted, they do what Dennis did with Compiz++. Send a mail,
detailing exactly what the piece of code does. Pros and Cons. Plans
for merging, and how it would affect current and future development. I
don't care that parts of it was explained in a conference call, that's
not the way to work. We can't have a conference call every time we
need to make a decision.

Don't get me wrong, the only person who can do this, is the person who
did the work. Dennis explaining Compiz++, David explaining Nomad.
There's no other way, and you can't out source documentation either.

And frankly, we can have as many conference calls as we want, it's not
Mail as a medium that's "broken", it's the communication
skills of the
people involved. Yes, I'm looking at YOU AGAIN David.

I will attend the conference call, because if I can't stop it, I might
as well join it now that I know ahead of time (that I missed it last
time was my fault, though). However, I still consider mail the only
real way to communicate. We have people living in different time
zones, and for most of us, it's hard enough to get time for Compiz as
it is.

I also want to note that time is relative. When a project is fun and
rewarding to work with, people tend to find more time for it. Which
makes it alarming how little time we find for Compiz.

- Kristian