[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    RE: KDevelop UI
From:       "Kris Wong" <wongk () seapine ! com>
Date:       2007-07-20 17:56:26
Message-ID: D1EF2A02037CA74CBC1C6AF3F5E0F7310249AE20 () ex3 ! seapine ! com
[Download RAW message or body]

> 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

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]