Re: KDevelop UI

On 20.07.07 08:31:52, Kris Wong wrote:
> > Yup, I'll be happy to do the merging work.  /me 0wns
svn. ;)
> 
> Have you guys tried this method before on this project?
 Speaking from
> experience, this can get rather nasty, rather fast. 
This becomes
> especially true in a highly unstable development
environment (like
> rewriting KDevelop basically from scratch).  I will
agree, there are
> benefits to this method.  I have found that negatives
generally outweigh
> the positives.  Of course, Matt is the person who would
have to deal
> with all of this, so if he is willing to sign up for
it... ;)

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.

Andreas

-- 
Today is the first day of the rest of your life.

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

> 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?  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...  The longer these branches exist and the
more that exist
would mean the further apart the common code in each branch
would
become.  Merging this back together and trying to make sure
everyone's
changes end up in trunk w/o overwriting other's changes is
difficult.
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.

Kris Wong

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

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.

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

> 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-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel