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

List:       kdevelop-devel
Subject:    Re: KDevelop UI
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2007-07-20 13:05:26
Message-ID: 20070720130526.GA9594 () morpheus ! apaku ! dnsalias ! org
[Download RAW message or body]

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