RFC: Moving forward with KDevelop plugins

[Milian Wolff]

On Thursday, August 13, 2015 12:02:14 PM Aleix Pol wrote:
> 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.

+1, please go ahead in doing this Kevin!

Also note that at Akademy I proposed to rip out oldcpp and replace it by kdev-
clang. Could you do that as well please? The reasoning here is similar:

We want people to use and test kdev-clang and we want to ship that by default 
with KDevelop 5. If people don't like that, or rely on features in oldcpp, 
they can stick to KDevelop 4 (or go to the trouble of compiling it themselves 
for KDevelop 5).

Medium-term though I plan to kill oldcpp off completely, which would allow us 
to cleanup large parts of the DUChain code which is only there for oldcpp's 
needs.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150813/f8d1521e/attachment-0001.sig>