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
managers?
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
Attachments: