Re: KDevelop UI

On 20.07.07 00:23:51, Roberto Raggi wrote:
> Hi Alexander,
> 
> Il giorno 19/lug/07, alle ore 23:48, Alexander Dymo ha
scritto:
> > Looking at commit rates for KDevelop in 2007 I
wouldn't say it's a
> > dead project ;) But yes, it doesn't look as good.
I have been thinking
> 
> I know, but I'm talking about KDE/KDevelop users that
are trying/ 
> evaluating KDE 4 beta.

KDevelop is not part of the upcoming KDE4 beta and wasn't
part of the
alpha2 that was released. 

It was part of the alpha1, but I think just due to the lack
of
communication (i.e. nobody asked us wether we want to
release with KDE
4.0)

> > of using KDev4 every day for a long time to make
sure its UI is any
> > good... but I never had enough time to start...
> 
> I want to propose an alternative solution. I think part
of the  
> problem is the high commit rate in /trunk. From what I
can see /trunk  
> is very unstable and don't tell me it works for you,
because it  
> doesn't and it is two years that kdev4 does not work
 So,
my  
> proposal. For one month you don't develop your
feature-X in trunk,  
> but you do it in /branches/kdevelop/whatever/feature-X
then when you  
> think that your code is good enough you ask Matt to
merge the change  
> in /trunk. If you merge only *good* changes in /trunk
you will improve 
> (by definition) the quality and the stability of
KDevelop. Branching  
> in svn is easy and cheep, merging is a different story
(more tricky),  
> but that's OK because you don't have to do it, Matt (as
maintainer)  
> will do it for you  if you
don't like svn you can maintain your  
> branch using git or mercurial.

There's at least one flaw in your proposal: Matt doesn't
have the time
(apparently) to do that. Also I don't really see how that
helps, because
these branches would live really long. I mean I currently
think that
include-dir stuff for qmake will take about at least 2 more
months and
thats only when I don't get a full-time job within that
timeframe (which
I hope I will). I personally don't see us releasing anywhere
close to
KDE 4.1 if the pace keeps as it is currently.

Andreas

-- 
You will have a long and boring life.

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

Hi!

Il giorno 20/lug/07, alle ore 00:54, Andreas Pakulat ha
scritto:
>
> KDevelop is not part of the upcoming KDE4 beta and
wasn't part of the
> alpha2 that was released.
>
> It was part of the alpha1, but I think just due to the
lack of
> communication (i.e. nobody asked us wether we want to
release with KDE
> 4.0)

yes, but what do you think is the first thing that a
KDevelop 3.x  
user will do after he installed KDE 4? start emacs?

>
> There's at least one flaw in your proposal: Matt
doesn't have the time

if Matt doesn't have time you can merge your change as long
as the  
change does not introduce regressions

> (apparently) to do that. Also I don't really see how
that helps,  
> because
> these branches would live really long. I mean I
currently think that

that's not true. You don't have to merge when the feature is
 
finished. You have to merge when you have something! and
that  
something is good enough for /trunk.


> include-dir stuff for qmake will take about at least 2
more months and
> thats only when I don't get a full-time job within that
timeframe  
> (which

I understand that, but I hope you understand that a feature
that does  
not work is useless for other developers. It's true that the
final- 
awesome-version of the qmake project manager needs 2 months,
but it  
is also true that you will have many
good-enough-to-be-integrate-in-/ 
trunk versions of the qmake project manager in the next
weeks.


> I hope I will). I personally don't see us releasing
anywhere close to

good luck 

ciao robe


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