RFC: Moving forward with KDevelop plugins

Aleix Pol aleixpol at kde.org
Thu Aug 13 10:02:14 UTC 2015

On Wed, Aug 12, 2015 at 10:31 PM, Kevin Funk <kfunk at kde.org> wrote:
> Heya,
> this is a topic I've been pondering about for quite a long time already...
> Currently, we have quite a few interesting plugins in different repositories,
> unfortunately they're not available to the wider audience because people still
> have to compile them in order to try them out.
> I'm thinking of kdevelop.git to hold all the tools you need for general C++/Qt
> development. We're mainly a C++/Qt IDE after all, and we should focus on
> providing an excellent experience "out of the box" on that matter.
> Currently, we have kdev-qmake and kdev-qmljs, both highly useful plugins for
> our audience, but in separate repositories. I'm proposing to merge them into
> kdevelop.git. For obvious reasons: It makes them available "out of the box",
> users don't need to install extra packages; and *we* don't need to wait until
> packagers decide it's a good time to package those *at all*. There's still no
> official kdev-qmljs package available for Debian/Ubuntu for instance, it just
> takes a lot of time and nagging to get there [1].
> My proposal:
> - Move kdev-qmake, kdev-qmljs into kdevelop.git
>   (Very much desired from my side)
> - Move kdev-valgrind, kdev-cppcheck, kdev-krazy, ..., into kdevelop.git
>   (Nice, too, they're all C++ related after all. Could be disabled by default)
> - "Bigger" language extensions, such as kdev-python, kdev-ruby, ...,
>   stay in their resp. repository (-> separate package)
> Issues:
> - kdev-qmake depends on kdevelop-pg-qt. But personally I wouldn't have a
> problem creating a dep on kdevelop-pg-qt for KDevelop. kdevelop-pg-qt is
> mostly static and can be considered almost a "framework", it's not a fast-
> moving target as kdevplatform
> - Some of the plugins, like the small checker plugins are in early stages. But
> honestly, if we don't get the out we'll never get them tested^Wused by our
> users. (-> "release early, release often")
> What do you think? I'd be happy to do the work if we come to an agreement. We
> can do a subtree-merge of all the plugins and keep the Git history, this is
> not an issue.
> I'd really like to drive KDevelop forward; we have lots of feature but don't
> let the user enjoy them. Let's make it easier!
> Cheers,
> Kevin
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777591
> --
> Kevin Funk | kfunk at kde.org | http://kfunk.org
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kdevelop-devel

I like the idea. I don't think it's about packagers though, it's
mostly that we decided not to release these because they are not all
that stable. Especially kdev-qmake.

If we think a plugin is useful enough, it should be merged.


More information about the KDevelop-devel mailing list