[compiz] Move KDE Plasma Integration to KDE Git Infrastructure

[Martin Gräßlin]

On Thursday 20 January 2011 21:00:23 you wrote:
> On Sun, Jan 16, 2011 at 05:07:46PM +0100, Martin Gräßlin wrote:
> > Up to now Compiz has done a great job of supporting our additions, so
> > that Compiz users get the same level of integration as KWin users.
> > Nevertheless due to the fact that releases are out of sync Compiz users
> > do not get new features when KDE has a release. This gets to a real
> > problem when KWin changes the decoration API as that causes
> > KDE4-Window-Decorator to crash (this is the most often reported bug
> > against KWin). This has let to a stagnation in our decoration API as we
> > don't dare to touch the code again. Nevertheless I plan to change the
> > API in 4.7 and our most prominent decorations (Oxygen and Aurorae) will
> > move to it.
> > 
> > Now with the git transition there might be a solution for these kind of
> > problems: Compiz's KDE Plasma integration is moved to KDE's
> > infrastructure and could be released in sync with the rest of Plasma.
> > This means you don't have to care about the release (done by KDE's
> > release team). Additionally you get the advantages of the KDE community
> > like the Krazy checks [1] and developers going through the code and fix
> > common issues. Translation would be provided by KDE's translation
> > infrastructure ensuring that the code is translated into all the
> > languages KDE supports and providing a consistend translation.
> 
> There's an obvious solution that hasn't been mentioned.
> 
> Git is distributed.
> 
> Keep it both with kde and compiz.org. Sync up whenever necessary. No issues
> with commit privileges, benefits from the KDE-community, no political
> issues, translation-benefits, support for all versions of Compiz, and so
> forth.
That would be the first solution: own repository in KDE. But it still has some 
problems which would need to be solved. E.g. to push a commit to KDE's git 
repo, the committer must have an account. But we have awesome sysadmins to 
help on that if we agree on going such a way.
> 
> The only issue that would remain is ensuring co-operation, but that's no
> different from how it is now. With two repositories of difference
> "interest", you also emphasis that the code is glue that affects two
> worlds.
> 
> > The last point gets me directly to where to move the code. There are
> > several options:
> > 1. Own repository either in extragear or as part of KDE SC. KDE SC would
> > mean releases synced with rest of KDE.
> 
> Regardless of the conclusion, it should remain as its own repository. We
> moved the decorators out of the core repository for several reasons, and
> moving it to a different repository voids that.
Which rules out the option to have it in workspace as AFAIK KDE's git 
infrastructure does not support submodules. But it would be something to 
revalidate with sysadmins.
> 
> > 3. Part of KWin. That is same as option 2, plus you could use KWin
> > internal code. E.g. no need to duplicate decoration code any more, make
> > use of KWin parts separated from core (e.g. Alt+Tab). This is probably
> > the best integration you could get.
> 
> Maintaining something you need to run a window manager (Compiz) in a
> repository of a different window manager(KWin) doesn't really add up. I see
> your logic from the KWin perspective, but not the Compiz-perspective.
Well for Compiz I see there a better integration into Plasma, the "official 
blessing" from a competitive project and of course the chance for improving 
the existing integration (there are several things I would like to see 
improved, e.g. swap KWin's configuration modules against Compiz's when Compiz 
is used) and more collaboration (in that regard the refactoring work might 
become handy).
> 
> - Kristian
> 
> PS: I'm CC'ing the compiz list that's not at xorg, as the xorg
> list is not the preferred list. (Our fault...)
thanks, I just picked the first one in my inbox - both are too low traffic to 
know which one is the real ;-)

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/compiz/attachments/20110120/e663339f/attachment.pgp>