KDevelop UI

[Andreas Pakulat]

On 20.07.07 13:07:58, Kris Wong wrote:
> > Could you elaborate a bit? I mean changes in kdevplatform shouldn't be
> > that common anymore (except when somebody fixes the profile system and
> > for the ui library, but these two mostly don't interact with the
> > plugins). I think for the various plugins that kdevelop is composed of
> > it does make sense to implement a new feature in a feature branch and
> > merge back as soon as you've got something useful.
> > 
> > I think for the plugins this should work pretty well, as they 
> > are nearly
> > self-contained and in most cases only 1 person works on a plugin at a
> > given time. I think with some extra communication (as in a 
> > notification
> > mail that feature X will be developed in branches/work/kdevelop4-X) it
> > could work out well.
> 
> Do you really think the platform is stable at this point?

There's quite some space between rock-solid-stable and
changing-every-hour-unstable ;)

> I imagine there would be small commits by different people in the
> platform, interface changes that cause other areas of the code to need
> to be updated, etc...

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".

> The longer these branches exist and the more that exist
> would mean the further apart the common code in each branch would
> become.

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.

> Merging this back together and trying to make sure everyone's
> changes end up in trunk w/o overwriting other's changes is difficult.

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.

> It is difficult here were I have direct access to everyone in the
> office.  It becomes even more so with a distributed development team.
> Please keep in mind I am not trying to prevent this from happening
> persay, but I just want to make sure we are all aware of the risks
> involved.

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)

Andreas

-- 
Next Friday will not be your lucky day.  As a matter of fact, you don't
have a lucky day this year.