KDevelop 4.0 Release
David Nolden
zwabel at googlemail.com
Mon Sep 8 21:53:21 UTC 2008
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.
> > 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.
Moving stuff to playground greatly reduces the probability that it's going to
be picked up, it's like a jungle of 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.
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.
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.
Greetings, David
More information about the KDevelop-devel
mailing list