Re: Seeking Mentorship and Guidance for "Mechanical Sphere" Proposal

[Benson Muite]

On 02/01/2024 08.23, Ritu Verma wrote:
> Thanks a lot for sharing.
> 
Welcome. As described in the wiki, do create an issue in Invent:
https://invent.kde.org/teams/season-of-kde/2024

While not KDE projects, you might also examine CAD software that uses Qt:
- FreeCAD https://github.com/FreeCAD/FreeCAD
- LibreCAD https://github.com/LibreCAD/LibreCAD
- QCAD https://github.com/qcad/qcad
- openscad https://github.com/openscad/openscad/
> On Tue, 2 Jan 2024 at 9:16 AM, Benson Muite  <mailto:benson_mu...@emailplus.org>> wrote:
> 
> On 01/01/2024 17.02, Ritu Verma wrote:
> > Hello,
> >
> > I'm currently working on a proposal for SoK 2024. However, I recognize
> > the importance of having a mentor from the core team to provide
> valuable
> > insights and guidance throughout the proposal development process. 
> >
> > Let me briefly explain my idea: I want to build an
> All-in-one-mechanical
> > tool named *Mechanical Sphere *for engineers that assist them with IS
> > Steel table, Metal Calculator, Flat pattern analyzer, Cone
> > calculator, Fabrication Calculator, Tank Volume Calculator.
> > I also would like to hear your thoughts on structuring and
> presenting a
> > compelling proposal. I understand that your time is precious, and I
> > would be immensely grateful for the opportunity to discuss my project
> > and proposal with you. I can tell you that I am flexible with the
> format
> > and timing of our discussion. I am open to adjusting based on your
> > schedule.Your timely assistance would be invaluable. Thank you for
> > considering my request, and I appreciate your commitment to supporting
> > the community.
> >
> Hi Ritu,
> Welcome to KDE - please use the KDE devel list for this:
> https://mail.kde.org/mailman/listinfo/kde-devel
> <https://mail.kde.org/mailman/listinfo/kde-devel>
> as described on the wiki:
> https://community.kde.org/SoK/Ideas/2024
> <https://community.kde.org/SoK/Ideas/2024>
> Please also subscribe to:
> https://mail.kde.org/mailman/listinfo/kde-soc
> <https://mail.kde.org/mailman/listinfo/kde-soc>
> 
> Benson
> 

Re: Markdown Tools - Request for a Sponsor

[Benson Muite]

On 15/03/2024 15.53, Igor Mironchik wrote:
> Hello,
> 
> Well ghostwriter looks the same one, live HTML preview.. Mmmm, looks nice.
> 
> But... My Markdown Tools handle internal links in the HTML preview, it
> can generate HTML preview for all linked Markdown files. Look at the
> menus, try it.
> 
> It supports CommonMark 0.31.2 with all major GFM extensions.
> 
> It can export to some clever PDF out of the box with handling internal
> links.
> 
> A little effort and Markdown Tools will be much more better any existing
> Markdown editor.
> 
> Guys, try it. It's just a proposal. No is no - and I'm gone.

Is there a roadmap? Might it be possible to integrate other markup
formats, for example AsciiDoc
> 
> On 15.03.2024 15:22, Ingo Klöcker wrote:
>> On Freitag, 15. März 2024 12:16:30 CET Igor Mironchik wrote:
>>> https://invent.kde.org/imironchik/markdown-tools/-/issues/1
>>>
>>> This is a set of applications to work with Markdown, including
>>> editor, HTML
>>> preview viewer, converter to PDF.
>> Do you know https://apps.kde.org/ghostwriter/?
>>
>> Regards,
>> Ingo

Re: Markdown Tools - Request for a Sponsor

[Benson Muite]

On 15/03/2024 16.20, Igor Mironchik wrote:
> 
> On 15.03.2024 16:01, Benson Muite wrote:
>> Is there a roadmap? Might it be possible to integrate other markup
>> formats, for example AsciiDoc
> 
> 
> Do we have any C/C++ Open Source Parser for AsciiDoc? Fully-featured,
> tested...
> 

Not at present unfortunately. Main implementation is Ruby, which can be
compiled to Javascript or a Java library. There is also a Python
implementation and ongoing work to produce Haskell and Rust implementations.

Re: Markdown Tools - Request for a Sponsor

[Benson Muite]

On 17/03/2024 13.25, Igor Mironchik wrote:
> 
> On 17.03.2024 10:33, Benson Muite wrote:
>> On 15/03/2024 16.20, Igor Mironchik wrote:
>>> On 15.03.2024 16:01, Benson Muite wrote:
>>>> Is there a roadmap? Might it be possible to integrate other markup
>>>> formats, for example AsciiDoc
>>>
>>> Do we have any C/C++ Open Source Parser for AsciiDoc? Fully-featured,
>>> tested...
>>>
>> Not at present unfortunately. Main implementation is Ruby, which can be
>> compiled to Javascript or a Java library. There is also a Python
>> implementation and ongoing work to produce Haskell and Rust
>> implementations.
> 
> 
> Well, by mistake I wrote md4qt. I know what this work is (parse Markup
> languages). It's not so trivial task, and it needs a lot of time to
> write and test such things. But I didn't say no. If I have md4qt, where
> I have Document for a tree representation, I can have a look at AsciiDoc
> and write something like asciidoc4qt, that will use the same structures
> for parsed document. In this case we can use absolutely the same
> converter to PDF.
> 
> I can start such thing. Ok. Does AsciiDoc have well documented format?
Yes.
> Does it have a set of tests?
> 
> I don't know how complicated AsciiDoc format is, maybe it's simpler of
> Markdown?
> 
It is more complicated than Markdown as it is more complete and allows
for some self-consistent extensibility.
> Markdown, despite its apparent simplicity, is a little complicated in
> implementation. I've made 356 commits to implement and test it, and
> spent some time for it, but it worth it.
> 
> In case of markdown-tools, if it will support CommonMark 0.31.2 with
> major GFM and latest AsciiDoc, will you accept my project?
> 
Cannot answer whether the project will be accepted, am not a sponsor.
It seems you are following the  review process.

There is a lack of tools for AsciiDoc, but would not make that the
primary concern.  If it can be done, it would be nice, but it seems
challenging.

Re: Markdown Tools - Request for a Sponsor

[Benson Muite]

On 17/03/2024 20.40, Igor Mironchik wrote:
> 
> On 17.03.2024 18:54, Benson Muite wrote:
>>> Does it have a set of tests?
>>>
>>> I don't know how complicated AsciiDoc format is, maybe it's simpler of
>>> Markdown?
>>>
>> It is more complicated than Markdown as it is more complete and allows
>> for some self-consistent extensibility.
> 
> More complete is not more complex for parsing... In Markdown a lot of
> complexes. But I will think on it.
> 
>> There is a lack of tools for AsciiDoc, but would not make that the
>> primary concern.  If it can be done, it would be nice, but it seems
>> challenging.
> 
> 
> The problem is that I see users of AsciiDoc even less of Markdown...
> 

Markdown is very popular, but in many applications it is extended in non
standard ways. Org mode is another readable markup language, but unlike
Asciidoc it seems to have C++ libraries:
https://github.com/mirkoboehm/OrgModeParser
https://github.com/haxscramper/haxorg

Most org mode users use Emacs, but giving an alternative editor may be
useful.

Re: [GSoC] Interest in applying

[Benson Muite]

Olá,

On 31/03/2024 16.16, tmpod wrote:

> After carefully reading your approved ideas page, the ones that
> stand 
>   out more to me are:
> * Improving Lokalize's suggestions (I'm a big supporter of quality i18n)

Thanks for your interest in this. Please subscribe to:
https://mail.kde.org/mailman/listinfo/kde-i18n-doc/
You may wish to also join the associated Matrix room:
https://go.kde.org/matrix/#/#kde-i18n:kde.org

There is also a Portuguese mailing list:
https://mail.kde.org/mailman/listinfo/kde-i18n-pt

> * Sharing non-text clipboard content with KDEConnect (KC is an amazing
>  and pretty unique tool)
> * Improve forms/javascript support in Okular (I think Okular is a great
>  PDF reader already, but it does lack good forms support, something
>  increasingly more useful nowadays)
> 
> I am aware of the very tight deadline and that it may be hard to write a
> community-backed proposal now, but unfortunately I was only made aware
> of Google's program a couple of days ago. Still, I'm going to try my
> best to write a quality proposal until Tuesday.
> 
> If you have any suggestions, please let me know!

Typically need to find a mentor - many people do start applications
early and have made prior contributions to KDE.  In addition to the
contact methods listed for each of the projects you find interesting,
you might also want to post to:
https://go.kde.org/matrix/#/#kde-mentorship:kde.org

KDE does also organize Season of KDE at the beginning of every year,
https://mentorship.kde.org/sok/
though contributions to KDE projects are welcome also outside of these
programs.
> I'd love to further discuss these with you.
> 
> Kind regards,
> 
> ~tmpod
> 
> 
> PS: To all celebrating Easter (and not hehe!), I hope you have wonderful
> Sunday.

Re: End of Year documentation sprint

[Benson Muite]

On 13/12/2024 4.04 pm, Farid Abdelnour wrote:
> Hey community
> 
> Join the End of Year documentation porting sprint effort to move from
> Doxygen to Qdoc.
> 
> Very soon™ we will be providing Python and Rust bindings for the KDE
> Frameworks and we would like to welcome these communities with a brand
> new and crisp documentation.
> 
> Grab one of the open tasks  sprints/-/boards> and come join us. We'll be hanging out every day in
> the Matrix room 
> working on this.
> 
> Check out the instructions  streamlined-application-development-experience/-/issues/10#note_1052720>
> on how to get started.

Maybe some of these tasks or related tasks could be posted as Season of
KDE Projects?
https://mentorship.kde.org/sok/
https://community.kde.org/SoK/Ideas/2025

> 
> Hope to you there!
> 
> Cheers
> 
> -- 
> Farid Abdelnour - KDE Goal Project Coordinator
> https://kde.org/goals 

Re: Review: Mankala-Engine, Mankala-GUI

[Benson Muite]

Hi Johnny,

On Sat, Apr 26, 2025, at 12:08 PM, Johnny Jazeix wrote:
> Hi Benson,
>
> As the project was started inside KDE, it has to follow the review
> process: https://develop.kde.org/docs/getting-started/add-project/#kde-review
> (there is a checklist).

Thanks. Updated.

>
> Cheers,
>
> Johnny
>
> Le sam. 26 avr. 2025 à 06:25, Benson Muite
>  a écrit :
>>
>> Hi,
>>
>> Would like to start the process for putting Mankala-Engine and Mankala-GUI 
>> through incubation.  The aim is to add a suite of Mankala games to KDE and 
>> develop more of people with knowledge of implementing artificial 
>> intelligence and machine learning capabilities within KDE.  The relevant 
>> repositories are:
>> https://invent.kde.org/joaotgouveia/mankalaengine
>> https://invent.kde.org/ashutoshhh/mancala-gui
>>
>> Regards,
>> Benson

Re: Incubation: Mankala-Engine, Mankala-GUI

[Benson Muite]

On Sat, Apr 26, 2025, at 3:46 PM, Albert Astals Cid wrote:
> El dissabte, 26 d’abril del 2025, a les 6:24:24 (Hora d’estiu d’Europa 
> central), Benson Muite va escriure:
>> Hi,
>> 
>> Would like to start the process for putting Mankala-Engine and Mankala-GUI
>> through incubation.  The aim is to add a suite of Mankala games to KDE and
>> develop more of people with knowledge of implementing artificial
>> intelligence and machine learning capabilities within KDE.  The relevant
>> repositories are: https://invent.kde.org/joaotgouveia/mankalaengine
>> https://invent.kde.org/ashutoshhh/mancala-gui
>
> mancala-gui is repo empty.

Main code is in a branch:
https://invent.kde.org/ashutoshhh/mancala-gui/-/tree/work/ashutosh/initial_pages?ref_type=heads

Not quite as developed as the engine, but maybe it is more efficient to have 
them reviewed together.

>
> Cheers,
>   Albert
>
>> 
>> Regards,
>> Benson

Incubation: Mankala-Engine, Mankala-GUI

[Benson Muite]

Hi,

Would like to start the process for putting Mankala-Engine and Mankala-GUI 
through incubation.  The aim is to add a suite of Mankala games to KDE and 
develop more of people with knowledge of implementing artificial intelligence 
and machine learning capabilities within KDE.  The relevant repositories are:
https://invent.kde.org/joaotgouveia/mankalaengine
https://invent.kde.org/ashutoshhh/mancala-gui

Regards,
Benson

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Benson Muite]

Code contributions made using AI trained on unknown data is problematic.  KDE 
does also create a lot of data that could be used to improve KDE. It may be 
good to see if AI or ML tools could use some of this data to improve KDE in an 
ethical manner.

On Thu, May 15, 2025, at 5:09 PM, Felix Ernst wrote:
> Late reply, but I also wanted to mention that I am 100% in support of 
> any anit-AI messaging and policies we might choose.
>
> The wording as linked by Akseli in their first post seems like a good 
> starting point in that regard:
>
>>Other projects have already done something similar, see for example:  
>>https://discourse.gnome.org/t/loupe-no-longer-allows-generative-ai-contributions/27327
>
> The only use of AI I support needs all its training data to be licenced 
> in a way that allows use for the AI training e.g. CC0 or WTFPL licence. 
> This way I don't see ethical issues because the copyright holders have 
> then given some sort of consenst for this use.
>
> I wouldn't even mind if we went one step further and actively promoted 
> e.g. Plasma as "free of AI". This does not need to be fully true, but 
> this would be more of an activism and marketing angle I would like to 
> see. There is a good chance though that this would not be a good use of 
> our time but it would align with KDE Eco IMO. (I know that there are 
> also great uses of AI, but public messaging needs to be clear and easy 
> to understand, and there is still enough pro-AI marketing out there to 
> the point that taking the opposite stance seems sensible to me.)
>
> Have a nice week!
> Felix
>
>  > Date: Tue, 13 May 2025 09:22:22 +0930
>  > From: Justin Zobel 
>  > 
>  > I am 100% for this. Most AI tools just scrape (read: steal) code 
> from 
>  > whatever source they can, with no attribution or consideration for 
> legal 
>  > rights/copyright.
>  > 
>  > Accepting any AI generated code is a legal risk unless the source of 
> the 
>  > code can be verified.
>  > 
>  > I would wager 99.999% of people using AI tools wouldn't know what 
> the 
>  > source of the code is, or how it is licensed.
>  > 
>  > On 12/05/2025 22:23, Akseli wrote:
>  > > Hi
>  > >
>  > > There's been a lot of "AI" slop spam to various KDE projects, bug 
> reports, forums, etc..
>  > >
>  > > We should take a more public stance on disallowing all this slop. 
> Lengthy gitlab issues that are just full of nonsense generated by a bot 
> just take time out of everyones schedules, trying to decipher if its 
> serious or not.
>  > >
>  > > Other projects have already done something similar, see for 
> example:https://discourse.gnome.org/t/loupe-no-longer-allows-generative-ai-contributions/27327
>  > >
>  > > I don't care if someone uses those tools in their personal 
> projects, but bringing this slop in to our shared space just frustrates 
> people and eats resources to go through.
>  > >
>  > > Can we have somekind of official "please don't AI slop in our 
> places" sign somewhere?
>  > >
>  > > Thanks,
>  > > - Akseli

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Benson Muite]

On Thu, May 15, 2025, at 9:28 PM, Alexander Potashev wrote:
> Hi Benson, (everyone,)
>
>> Code contributions made using AI trained on unknown data is problematic.
>
> Is this purely a legal/intellectual property concern?
>

This is a concern.  People have pointed out others.

>
> If we can generalize this concern as
>
> "a contributor submits code incompatible with the project's license,
> thus breaching the license"
>
> , not only AI may put the project in trouble. It can be at least one of
> these scenarios:
>  1. The code the contributor submitted was generated by AI and originates
> from e.g. another open source project distributed under an incompatible
> license.
>  2. The contributor steals proprietary code and submits it to an open
> source project (no AI involved).
>
> By banning the use of AI, you don't fully solve the legal risk.
>
>

This is true. Banning AI is not a solution.

> On Thu, May 15, 2025 at 7:08 PM Benson Muite 
> wrote:
>
>>
>> Code contributions made using AI trained on unknown data is problematic.
>> KDE does also create a lot of data that could be used to improve KDE. It
>> may be good to see if AI or ML tools could use some of this data to improve
>> KDE in an ethical manner.
>>
>> On Thu, May 15, 2025, at 5:09 PM, Felix Ernst wrote:
>> > Late reply, but I also wanted to mention that I am 100% in support of
>> > any anit-AI messaging and policies we might choose.
>> >
>> > The wording as linked by Akseli in their first post seems like a good
>> > starting point in that regard:
>> >
>> >>Other projects have already done something similar, see for example:
>> https://discourse.gnome.org/t/loupe-no-longer-allows-generative-ai-contributions/27327
>> >
>> > The only use of AI I support needs all its training data to be licenced
>> > in a way that allows use for the AI training e.g. CC0 or WTFPL licence.
>> > This way I don't see ethical issues because the copyright holders have
>> > then given some sort of consenst for this use.
>> >
>> > I wouldn't even mind if we went one step further and actively promoted
>> > e.g. Plasma as "free of AI". This does not need to be fully true, but
>> > this would be more of an activism and marketing angle I would like to
>> > see. There is a good chance though that this would not be a good use of
>> > our time but it would align with KDE Eco IMO. (I know that there are
>> > also great uses of AI, but public messaging needs to be clear and easy
>> > to understand, and there is still enough pro-AI marketing out there to
>> > the point that taking the opposite stance seems sensible to me.)
>> >
>> > Have a nice week!
>> > Felix
>> >
>> >  > Date: Tue, 13 May 2025 09:22:22 +0930
>> >  > From: Justin Zobel 
>> >  >
>> >  > I am 100% for this. Most AI tools just scrape (read: steal) code
>> > from
>> >  > whatever source they can, with no attribution or consideration for
>> > legal
>> >  > rights/copyright.
>> >  >
>> >  > Accepting any AI generated code is a legal risk unless the source of
>> > the
>> >  > code can be verified.
>> >  >
>> >  > I would wager 99.999% of people using AI tools wouldn't know what
>> > the
>> >  > source of the code is, or how it is licensed.
>> >  >
>> >  > On 12/05/2025 22:23, Akseli wrote:
>> >  > > Hi
>> >  > >
>> >  > > There's been a lot of "AI" slop spam to various KDE projects, bug
>> > reports, forums, etc..
>> >  > >
>> >  > > We should take a more public stance on disallowing all this slop.
>> > Lengthy gitlab issues that are just full of nonsense generated by a bot
>> > just take time out of everyones schedules, trying to decipher if its
>> > serious or not.
>> >  > >
>> >  > > Other projects have already done something similar, see for
>> > example:
>> https://discourse.gnome.org/t/loupe-no-longer-allows-generative-ai-contributions/27327
>> >  > >
>> >  > > I don't care if someone uses those tools in their personal
>> > projects, but bringing this slop in to our shared space just frustrates
>> > people and eats resources to go through.
>> >  > >
>> >  > > Can we have somekind of official "please don't AI slop in our
>> > places" sign somewhere?
>> >  > >
>> >  > > Thanks,
>> >  > > - Akseli
>>

Re: Upcoming CI changes - transition to VM based CI

[Benson Muite]

On Mon, Jun 2, 2025, at 5:42 PM, Christoph Cullmann wrote:
> Hi,
>
>
> On Monday, June 2nd, 2025 at 13:40, Ben Cooksley  wrote:
>
>> Hi all,
>> For some time now we have had a variety of issues with our Docker/Podman 
>> based CI builds. These have included the lack of GUI test support on 
>> Windows, periodic crashes on FreeBSD, poor IO performance of Windows builds, 
>> issues supporting builds for Flatpak and Snaps and inability to support 
>> either builds or tests where elevated privileges or system session resources 
>> are needed.
>> 
>
>> In addition to this we've had issues where Linux CI builds have the 
>> capability to trigger OOM events on the CI hosts, which in turn takes out 
>> Windows and (less often) FreeBSD builders. While this does not occur too 
>> often, it does happen from time to time and eventually negatively impacts 
>> the build queue for those platforms.
>> 
>
>> The need to have dedicated VMs for FreeBSD and Windows on our builders also 
>> makes setting up of a CI build node for KDE software a more complicated and 
>> time intensive task than it otherwise needs to be (and means that the amount 
>> of systems to care for increases by 3 for every CI node we add).
>> 
>
>> While individually relatively minor, together these issues more than justify 
>> making a significant change to the way we run our CI system - in this case 
>> transitioning from container based builds to VM based builds.
>> 
>
>> These builds will still take place on dedicated hardware that we control, 
>> however instead of taking place within a container (managed by Podman on 
>> Linux and FreeBSD, or Docker on Windows) they will instead take place within 
>> a VM using a copy-on-write disk image.
>> VM based builds will unfortunately take a little longer to start (it takes 
>> ~10 seconds for a VM from any of Linux, FreeBSD or Windows to boot on my 
>> personal system) however the benefits we gain should more than outweigh this 
>> small downside.
>> 
>
>> This has been under development for the past couple of weeks and is now 
>> reaching the point where the only remaining steps are to get it integrated 
>> with the Gitlab CI agent (gitlab-runner) for which prototype code is already 
>> in place, and complete porting of our images over. Once that happens a 
>> complete rebuild of all of our builders will be swiftly undertaken to 
>> transition them completely over to the new VM based infrastructure.
>> 
>
>> Specs wise, at this time it is planned for each spawned standard VM to be 
>> provided with 2/3's of the system CPU cores (so 12 cores), 16GB RAM and 
>> 100GB of disk space (although some of that will be occupied by the system 
>> image - approximately 10GB for standard Linux builds and ~30GB or so for 
>> Windows builds). There will be a higher resource tier available for certain 
>> builds however that will be on request only and would need to be justified 
>> (such as Craft needing to build QtWebEngine).
>> 
>
>> As launching VMs is not the most efficient approach for all workloads, 
>> limited support for running Docker containers will be preserved, however 
>> this support is primarily intended for running linters, sanity checks and 
>> website builds, and is not intended for running general CI/CD builds.
>> 
>
>> The tooling used by the CI nodes to run VMs is something that should be 
>> fairly trivial for people to run on their own local system should they wish 
>> to run any of those images (say for FreeBSD or Android), although you will 
>> need to setup libvirt yourself (SUSE has very good instructions for this, 
>> Debian less so as their instructions lack installing the packages needed to 
>> provide UEFI and TPM support). The tooling itself was merged this evening to 
>> sysadmin/ci-images (vm-common/ folder) and can be used with the VM images 
>> found at https://storage.kde.org/vm-images/
>> 
>
>> There is however one downside to this - Qt 5 support.
>> 
>
>> Over the past few months distributions have been steadily removing packages 
>> and other supporting infrastructure needed to keep Qt 5 builds alive. In the 
>> case of Windows, support for the entire Qt 5 tree has been unmaintained for 
>> some time. For FreeBSD and SUSE a significant number of packages have been 
>> removed - which in the case of SUSE also includes packages needed to support 
>> the building of KJS. Accordingly, because builds of Frameworks are a first 
>> stepping stone to support building anything else, it will not be possible 
>> for us to produce Qt 5 based VM build images for any of the 3 platforms.
>> 
>
>> We will therefore have to remove Qt 5 support from the CI system with the 
>> transition to VM based CI.
>> 
>
>> Please let me know if there are any questions on the above.
>
>
>
> Have we some overview how many things on invent.kde.org will loose the 
> the CI as they are still Qt 5 only?

Happy to help upgrade some.
Upgrade for marK:
https://invent.kde.org/education/mark/-/merge_requests/10

Examin