KDevelop UI

[Kris Wong]

> Right. However if somebody changes an interface that is used, 
> he/she has
> to fix all uses of that interface or talk to the authors of the
> plugin(s) in question and coordinate the fixing. This can be 
> done inside
> the feature branch as well. And on the next merge to trunk 
> its still all
> "fixed".

Therein lies the problem.  If I were to fix something in an existing
piece of code that someone else is either working on, or was updated by
someone else, this will result in a merge conflict.

> Well, even if the branch exists for a longer period of time, its meant
> to be merged every now and then when a new subfeature works. Also
> currently few people work on the same plugins so for kdevelop there's
> not much common code anyway - thats all in kdevplatform.

This is the area where I forsee issues.

> I don't see the problem here as features are mostly done in separate
> parts of kdevelop (i.e. the plugins). For the platform its a bit
> different, but platform itself doesn't have all that much 
> logic (except
> shell/ and sublime) so I don't think it happens that much that you
> change something in platform and screw somebody else's changes by that
> even though it merges without conflicts... Also branches that 
> exist for
> a longer period of time (think > 1 month) should merge from trunk/ to
> branch occasionally.

Well, you can speculate, or take it from someone who's done this sort of
thing on many occasions in the past. =]  I'm sure some of the more
experienced devs out there know what I am talking about.

> Right, but as everybody is supposed to build and test before 
> committing
> (that includes building and running unittests as well as running the
> application) it shouldn't be that huge of a problem. (Hopefully)

Building and testing doesn't have anything to do with it.

Anyway, I've said pretty much all I'm going to say here since:
1. I'm not really that active anyway, and
2. I am not the one who will have to deal with this.

Kris Wong