Re: KDevelop UI

On 20.07.07 13:56:26, Kris Wong wrote:
> > 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.

And why is that a problem? Sure the conflict needs to be
resolved, but
the same thing happens if you work on trunk/ and don't
commit for a
while because your stuff is not done yet.

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

I wasn't purely speculating. If you look at the commits
there's been
really only little work done on any of the platform libs
(except
language which is changed due to SoC). And those changes are
not that
bug. 

And btw, I do have experience with developing everything in
trunk and
its not really any better IMHO.

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

Yes it does, it makes sure that combining your branch
changes and
changes happened in trunk don't break anything. Which might
happen even
though no merge conflicts arise.

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

Well, I'm not sure that letting Matt handle all merge's is
such a good
idea.

Andreas

-- 
Domestic happiness and faithful friends.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Ok, to branch or not to branch is not a question ;)
Let's say that if you work on smth big and lengthy that is
not
self-contained (aka plugin), you should better create a
branch. It's
just as simple as that.

But... the whole idea behind proposed branching policy is to
make sure
KDevelop is always stable (or at least usable). But I
believe that
having a branch is not enough. When you merge your branch
back, what
you usually know is that your new feature works. This means
other
features might easily become broken. So IMHO what we need
not to have
developer's branches, but rather we need to have (more)
tests.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel