> 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

Yes, and in principle I have always agreed with this.  However Martin does
not agree with the testing first and reverting if needed parts. :-)

Tim