Timothy Pearson wrote:
>> 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. :-)

With today's revision systems like Subversion and Git, I cannot imagine
this could really still prevent people from working together and sharing
code.
To me it even makes sense to have multiple branches with different
people working on them. This allows less stable development to continue
while a release is stabilized at the same time. I think with Git, such
branches can even be controlled by separate entities on otherwise
unrelated servers.

Julius