Timothy Pearson wrote:
>> Timothy Pearson wrote:
>>> However, twin will NEVER be completely deleted.  Why?  I don't like
>>> relying on an upstream project (KDE) that has a history of seriously
>>> breaking things in new releases (history is history and cannot be
>>> changed).  We need something to fall back on if kwin turns out to have
>>> serious problems (e.g. on certain graphics hardware), even if twin's
>>> codebase is never touched again.
>>
>> This doesn't really make sense to me. KDE 4 development never broke the
>> existing KDE 3.5 in any way. (It's also silly to say that the KDE
>> developers prevented people from enjoying KDE 3.5 after KDE 4 was
>> released.) If there would be a stable version of kwin4 working well with
>> Trinity in the future, it will always be possible to stick with that
>> version if newer versions would turn out to be problematic.
>>
>> I see no problems in using an upstream project here at all.
> 
> I guess if we kept a known working copy of kwin and only imported from
> upstream after stability testing then it would be viable to delete twin.

Combining efforts with kwin4 would mean that (large parts of) the code
will even be tested by more users (both Trinity & KDE 4 users).

I fully agree that extra testing is necessary (although this can
sometimes even be delegated downstream IMO). Not being afraid to revert
changes if they significantly break things or going back to (keeping) a
previous revision is important as well. This is basically how Trinity
was formed :)

KDE 4 took a certain path which was the reason to go back to KDE 3.5 and
develop Trinity from there. Any effort to take things from KDE 4 as they
evolved and adapt them so they can fit nicely again into Trinity along
with obviously many fixes that are also relevant for Trinity seems very
admirable. (Especially when initiated or proposed by KDE developers IMO.)

Julius