Akademy BoF wrapup, or: KDevelop 4 is about ten years old, how is it going to shine in the next ten years?

Christoph Roick chrisito at gmx.de
Sun Aug 19 14:27:34 BST 2018


I just want to provide my view as somebody who cares but currently doesn't 
have much time.
I mostly did bug fixes so far, which one year ago seemed pretty important. 
Since KDevelop has become more stable, I think new bugs became more 
complicated and less urgent.

Am Donnerstag, 16. August 2018, 22:02:26 CEST schrieb Sven Brauch:
>  - Consider removing or very pragmatically simplifying the implementations
> of these concepts. Make a list of workflows we want to support nicely in
> KDevelop, and try to identify buggy features that are not required by
> these.

Fixing plugins is fine, their location in the project is clear. But whenever I 
approached one of the core modules, getting through the abstraction layers 
required more time than actually understanding what the bug could be. So 
reducing the complexity of the code base is something I'm agreeing too and 
would like to support this. It could also be an opportunity to improve the 
documentation along the way.

>  - Identify things in KDevelop which significantly increase the complexity
> of the application, and do not really provide that much value to the user
> (because their functionality is limited, buggy, or easily provided by other
> means). A first list of these things could go like this:
>     * Working Sets
>     * Debug/Review areas, i.e. the whole Areas concept
>     * showing arbitrary document types inline (instead of only text
> documents) * unified version control interfaces for all VCS, instead of
> just implementing each on its own
>     * arbitrary split views instead of just split left/right

I agree with that list. I actually like the idea of working sets, but I think 
they should be less hidden. Also I usually don't use them because sets seem to 
disappear and reappear, without knowing how to reproduce or fix the behavior.

> In general, the situation in my eyes is that (even though recently it looks
> a bit better) there are not that many really active contributors in
> KDevelop. We have several people who care about the project, which is
> great, but most of them currently do not have the time to actively work on
> it.
> To improve this situation, we should somehow aim to improve the "amount-of-
> stuff-to-maintain" to "people-maintaining-stuff" ratio.

Probably a new "bigger goal" like the one you present could qualify new people 
(like me) to be maintainers and feel responsible for certain parts of the 
project once its done. Such that there's not a few people who are responsible 
for everything, but everyone has its own part to maintain. Continuing would 
probably leave the situation as it is, with people occasionally coming and 
leaving, without really remaining in the project.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180819/e8fbaa92/attachment.sig>

More information about the KDevelop-devel mailing list