KDevelop 4.0 Release

[Andreas Pakulat]

On 08.09.08 23:53:21, David Nolden wrote:
> Am Montag, 8. September 2008 23:14:20 schrieb Andreas Pakulat:
> > On 08.09.08 10:35:02, David Nolden wrote:
> > > I think stuff like the duchain viewer should stay in KDevplatform, nobody
> > > would even get the idea to try such a small thing out when it was lying
> > > in playground.
> >
> > Then I'd like to ask you what the purpose of the duchain viewer in a C++
> > IDE is?
> 
> It's only a debugging utilities for developers working on KDevelop, so it 
> should _never_ appear in any release. Still, nobody is going to use it when 
> it's in playground.

Uhm, thats the exact definition of playground (stuff thats not for a
public release) and I disagree that people don't use stuff from
playground. It just depends on how well you make people aware there's
something nifty there. Personally I'm using a game from playground every
other day, which I only know about because its been blogged about by the
author. Its pretty easy nowadays to have that, put it into the wiki. I
also plan to do some work on techbase to provide our own Project page
there with helpful pointers to our website.

> > > Then we
> > > can leave plugins that we want to have, but that aren't ready _yet_ and
> > > developer plugins like the duchain viewer, directly in the source tree.
> >
> > I disagree, plugins that want to be in the core kdevplatform module or
> > the kdevelop module should be ready for public use. Anything else either
> > needs to go to extragear or playground. We'd like to avoid the mess that
> > we had in kdevelop3 and we already started with that again - for example
> > the snippet support still has multiple bugs and gets no attention, or
> > cvs support which is also unmaintained since about a year I think.
> 
> I'm not talking about stuff that is unmaintained and that we don't think is 
> essential, I'm talking about stuff like the debugger, plugins that we core 
> developers think is absolutely needed, but that we cannot get ready for our 
> first release.

Uhm, a 4.0 release without gdb support won't happen. We've got a feature
plan written down which includes gdb support. Until that feature plan is
mostly done we won't start on a feature freeze - unless somebody can
convince me to do that :P

> Moving stuff to playground greatly reduces the probability that it's going to 
> be picked up, it's like a jungle of unmaintained code.

Thats not quite right. Yes there's probably a good bunch of unmaintained
stuff there, however module coordinators that have a related playground
module are supposed to look after it a bit, so it doesn't bitrot. In
general all KDE devs should make sure their code thats placed there
doesn't bitrot. playground is supposed to be a "do whatever your want,
no rules apply" area, not a dumping ground for unmaintained code.

> When we keep something in KDevelop, we can easily point new developers
> asking what they can do at it, or we can ourselves work on it when we
> feel like it, without a barrier.

Checking out a single plugin from playground and building it is
hardly a barrier. And its also easier for people to work on that stuff,
because

a) they only need to build kdevplatform once
b) they don't need to read all the extra buildsystem stuff from
kdevplatform, they can concentrate on the small plugin
c) I can't think of c) atm, but gimme some time and I'll come up with
something ;)

> I agree in what you're saying about avoiding the mess, I too don't want 
> KDevelop to be a gigantic set of half-baked plugins. I'm just talking about 
> stuff we think is important, that has a chance to be finished by someone, but 
> that isn't release-ready, considering that we want to do an early release.

To be 100% clear: Any plugin that hasn't been touched for a while and
has serious missing features (bugs can be fixed by all of us during the
feature freeze) will be moved to extragear or playground - depending on
the authors preference. Thats how you make sure that there's no mess of
half-baked plugins in the main modules. 

Having said that, currently IMHO duchainviewer, teamwork,
genericprojectmanger and cvs fall into that category with hg and bzr
support being candidates depending on Evgeniy's progress in the next
months. 

> Another option would be having something like kdevelop_unstable_extras in 
> playground, a central place where all the promising but unfinished plugins 
> can live until they're mature enough to be moved into the main tree.

We have that, except its called devtools/kdevelop4-extra-plugins.
Anything in there that is 'dead'[1] code will be moved to
tags/unmaintained/4 sooner or later by me. Even then its not completely
dead, it can be resurrected any time, we can even keep a list on the
wiki if we want to.

Andreas

[1] According to my current understanding dead means: code that doesn't
compile, has serious usability bugs, has multiple missing features and
in general hasn't seen any changes since 6 months.

-- 
Think twice before speaking, but don't say "think think click click".