> > Given the reasons it's now an orphan, I don't think
> it's wise for us to assume its maintenance (IIRC, Tim has already said he doesn't want
> to, anyway).  Best to move on.
> 
> Yep, I agree totally. The big question is my mind is (1)
> time & (2) manpower constraints to implement its removal
> from tde. Every kde3 project that wants to move forward must
> be addressing this issue. While it might seem unmanageable
> for TDE to do it alone, or SuSE to do it alone, or whoever
> to do it alone, if we could somehow coordinate TDE, SuSE and
> whoever else (need to ID these) so that a common framework
> is chosen and the parts of the transition broken down into
> block 1, 2, 3, .... so that TDE does 1, suse does 2, and so
> on -- it starts to look a whole lot more doable.
> 
> Why not have a central halfreetkde3-wiki or something
> similar that could host removal standards and server as a
> patch repository/hub....
> 
> Instead of having 10 different projects separately trying to
> do the same thing 10 different ways, it is far better to
> have 10 different projects contribute to doing 1 thing the
> same way....

We have little choice to "move on," but I want to see the existing HAL support remain intact and loosely maintained. At least for the next few releases and until the new detection mechanism is fully developed and mature, which will take a release or two to mature. I believe we can support both with build configuration options.

Keeping HAL support allows users to install Trinity on older hardware with older operating systems. We should remember that many people run older releases of operating systems for many years and do not play the relentless updating game.

Regarding collaboration, like most things in life, that either happens or doesn't. The people supporting KDE3 rather than Trinity have their reasons. We should respect those decisions and they should respect ours. At one time there was fallout because some people did not want the TQt layer. The only way we keep the doors open to those people to help with collaboration is to prove the layer does not cause problems or bugs. We should be honest with ourselves and admit that the transition to TQt did introduce bugs. I believe those growing pains are now behind us. When we demonstrate that no such related bugs exist then that might convince others to return. Until then we learn to be content with what we are doing and let others be content with what they are doing. :-)

Darrell