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