Message: previous - next
Month: December 2011

Re: Re: Re: Re: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4

From: Martin Gräßlin <mgraesslin@...>
Date: Sun, 11 Dec 2011 12:38:05 +0100
On Saturday 10 December 2011 14:14:50 Timothy Pearson wrote:
> Regardless, the process to drop/replace something is not trivial.  This
> project is not like other desktops; we don't just drop or replace things
> on a whim.
Once again: kwin4 is the continuation of kwin3. It is the same application! 
This would not be anything like "drop or replace things on a whim". (Btw. this 
sounds like a reference to KDE 4. I would suggest you to get away from such an 
attitude if you want to be on good speaking terms with KDE. Nobody in KDE 
replaces things on a whim.)
> The process would be:
> 1.) Develop a procedure to replace twin with kwin4 on users' test systems
> 2.) Those users would need to thoroughly test the replacement for many
> months, noting any regressions and having them fixed upstream.  Upstream's
> response time and overall regression rate would also be evaluated at this
> time.
To make it quite clear: we have our own release cycle and our own goals. There 
is no way to tell us that we have to fix specific bugs. We fix bugs based on 
how many users are affected or if we think it is a bug which needs to be fixed 
based on our goals.

If Trinity needs Trinity specific patches to KWin those would have to go into 
a branch. 
> 3.) If the replacement after testing looks viable then a deployment
> procedure would be created.  twin would still be available, but kwin4
> would be an option, either in build or in package installation
> (preferred).
> 4.) If the majority of end-users choose kwin4 at this point, then twin
> would be deprecated but still maintained as compilable in the TDE source
> tree.
> As you can see this is not trivial.  These guidelines are be applied to
> any integral component of TDE, including the HAL replacement, and are not
> meant to be an onerous set of rules to prevent progress.  Rather they are
> meant to lessen the possibility of sudden unexpected breakage for corner
> case users, as has been seen many times before in open source history.
I think that this process would not apply to such a change. Once again: it's 
the same application. I'm not asking you to replace twin by Compiz or any 
other window manager. It is just a later version. It's nothing like developing 
a new system such as udev support in replacement of HAL.

Once again I urge you to think about what you want to achieve and what you 
want to provide to your users.

"This project aims to keep the KDE3.5 computing style alive, as well as polish 
off any rough edges that were present as of KDE 3.5.10. Along the way, new 
useful features will be added to keep the environment up-to-date."

KWin4 still offers the same KDE3.5 computing style, but is highly polished and 
many rough edges which were present as of KDE 3.5.10 were removed. Just think 
about the 600 fixes I mentioned in my first mail.

I think that you want to provide the best possible KDE 3.5 computing 
experience to your users. Do you have to develop your own window manager for 
that? Do you have to work on a field which you do not understand? Is it not 
better to use what KDE provides in that area? An actively developed and 
maintained window manager with developers working for years on window 

I don't care what you want to develop on. I just see that you are not able to 
develop a window manager and what I offer here is help. Help to no longer need 
to develop a window manager. You can think about it and come to your own 
conclusion, or block everything without even considering it by just mentioning 
formal processes.

Think about what you want to achieve. What is the long term goal of Trinity. 
Somehow I have the feeling that you never really thought about where to go in 
two, three years.

Kind Regards
Martin Gr��lin