Re: Changing dependencies for a project

[Johnny Jazeix]

Hi,

To paraphrase Captain Tsubasa "the CI is your friend". If there was a
merge request, the build would have failed and you still would have
sent a mail here to ask how to add the dependency :). Even for smaller
changes, it's always interesting to have the CI run because it's quite
quick and can find small issues that can be avoided (for example, if a
file is added, it could be easy to miss to add the licence, the reuse
job will fail and in a wonderful world, the commit where the file has
been added would be amended to add the licence and we will have a
clean history. Or if a xml is not correctly formatted for example).

Heiko answered you for the process to add the dependency. And thanks
for the change, it's always nice to have up-to-date code!

Cheers,

Johnny


Le mer. 10 juil. 2024 à 01:52, David Jarvie  a écrit :
>
> On Tuesday, 9 July 2024 23:47:30 BST Albert Astals Cid wrote:
> > El dimarts, 9 de juliol del 2024, a les 22:12:40 (CEST), David Jarvie va
> >
> > escriure:
> > > I have just changed the dependencies for KAlarm (removed Canberra, added
> > > libvlc and libvlccore), but after committing the changes, the build fails
> > > on invent.kde.org.
> >
> > In the future probably helps if you do similar (or all) your changes as
> > Merge Requests instead of directly committing.
> >
> > This way you would have found this issue earlier and we would not end up
> > with a non compiling CI.
>
> If I'd created a merge request, it would presumably have just sat there
> unmergeable because of the missing CI dependency. How does a new dependency
> get added to the CI?
>
> > > I've changed everything I can find in the KAlarm repository
> > > relating to the dependencies, so is there something else I need to do to
> > > set up the new dependencies?
>
> --
> David Jarvie.
> KDE developer, KAlarm author.

Re: [GSoC Mentors] GSoC 2024 open for org applications January 22 - February 6

[Johnny Jazeix]

Hi Scarlett,

it is not too late. For now, we are in the state where KDE is accepted for
this year, and contributors reach us if they are interested. In March,
globally, potential contributors discuss with us, and submit in the second
half an application to the GSoC website. Then, in April, we rank them and
in May, Google tells us which projects we will mentor.

The full timeline is available in
https://developers.google.com/open-source/gsoc/timeline.

** Important **
As mentor, you need to register to kde-soc-men...@kde.org and
kde-...@kde.org (this one, for you and the potential contributor), it is
where we will send the information.
I've invited you to the website, you will have to sign the 2024 agreement
so we can add you as active mentor this year.

Cheers,

Johnny

Le ven. 1 mars 2024 à 17:22, Scarlett Moore 
a écrit :

> Hi all,
> I just had a prospective student approach me with some GSOC ideas in
> regards to snaps ( KDE side of things ) that I like. I am willing to
> mentor as well. However, I have no idea how this works. Are we too
> late? Is it still possible to get this in, if so, what do I need to do
> to make it happen?
> Thanks,
> Scarlett
>
> On Wed, Jan 10, 2024 at 2:16 AM Johnny Jazeix  wrote:
> >
> > Thanks Valorie,
> >
> > for info, the required tasks are mostly:
> > * on each specific period (
> https://developers.google.com/open-source/gsoc/timeline), send mails (to
> community to recruit people/gather ideas at first, then reminders to
> kde-soc and kde-soc-mentors for the next periods);
> > * create 2 blog posts (one at the beginning of the GSoC and one at the
> end - https://dot.kde.org/2023/05/16/kde-google-summer-code-2023 and
> https://kde.org/announcements/2023-gsoc-end/, written in markdown);
> > * be present in case there are issues to be dealt with
> > (* some administrative tasks but I'll probably handle all of them with
> the e.V.)
> >
> > Cheers,
> >
> > Johnny
> >
> > Here are all the mails sent last year to have an idea:
> > https://mail.kde.org/pipermail/kde-community/2023q1/007429.html
> > https://mail.kde.org/pipermail/kde-community/2023q1/007499.html
> > https://mail.kde.org/pipermail/kde-community/2023q1/007524.html
> > https://mail.kde.org/pipermail/kde-community/2023q2/007605.html
> > https://mail.kde.org/pipermail/kde-soc/2023-March/001634.html
> > https://mail.kde.org/pipermail/kde-soc/2023-May/thread.html
> > https://mail.kde.org/pipermail/kde-soc/2023-July/thread.html
> > https://mail.kde.org/pipermail/kde-soc/2023-August/thread.html
> >
> >
> > Le mer. 10 janv. 2024 à 03:35, Valorie Zimmerman <
> valorie.zimmer...@gmail.com> a écrit :
> >>
> >> I'm willing to remain on the list of co-admins, but will not be able to
> be more active than I was last year.
> >>
> >> Valorie
> >>
> >> On Tue, Jan 9, 2024 at 6:32 PM Johnny Jazeix  wrote:
> >>>
> >>>  Hi,
> >>>
> >>> Are there people willing to help co-admin this year? It would be nice
> to be at least 3 to share the workload.
> >>>
> >>> If mentors are interested, there will be a session Thursday (link sent
> to the mentor list, I've removed it from below as I'm not sure if it's
> supposed to be mentors only).
> >>>
> >>> Main point seem to be: "Starting in 2024 we will have small (~90 hour
> projects), medium (~175 hr projects) and large (~350 hour) projects
> available to GSoC contributors. 90 hours projects are optional."
> >>>
> >>> I've updated the skeleton wiki page to create the 2024 season:
> >>> https://community.kde.org/GSoC/2024/Ideas.
> >>>
> >>> Please start discussing among your teams what ideas will be great to
> have
> >>> this year and who is willing to mentor, as the organisation application
> >>> date needs to apply between the January 22 - February 6 and we need a
> wiki
> >>> page filled with ideas by then.
> >>> And please don't wait the last moment to fill the page.
> >>>
> >>> Cheers,
> >>>
> >>> Johnny
> >>>
> >>> -- Forwarded message -
> >>> De : 'sttaylor' via Google Summer of Code Mentors List <
> google-summer-of-code-mentors-l...@googlegroups.com>
> >>> Date: ven. 5 janv. 2024 à 00:28
> >>> Subject: [GSoC Mentors] GSoC Organization Application Info Session
> January 11th 1700 UTC
> >>> To: Google Summer of Code Mentors List <
> google-summer-of-code-mentors-l...@googlegroups.com>
> >>>
> >>>
> >>&

Re: Defining a developer name for our applications metadata

[Johnny Jazeix]

Hi,

Just to be sure, do we know which appstream version do we use to validate
our appdata files (
https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/master/kde-modules/appstreamtest.cmake)
and if the deprecated tag will issue a warning, an error or nothing in it?

Cheers,

Johnny


Le ven. 2 févr. 2024 à 16:56, Timothée Ravier  a écrit :

> Hi everyone,
>
> Following suggestions in the thread, I'll start updating our AppStream
> metadata with:
>
> ```
> KDE
> ```
>
> Thanks
> --
>
> Timothée Ravier
>
> CoreOS co-Team Lead
>
> Red Hat 
>
> trav...@redhat.com
> 
>

Re: Defining a developer name for our applications metadata

[Johnny Jazeix]

Hi,

I recently added an application in flathub and found
https://discourse.flathub.org/t/deprecated-developer-name-element/5746
which is related to the subject.
I used appstreamcli to generate the appdata and it changes
 to .
The new format emits a warning on flathub linter (missing developer_name
tag).

Do you know if it has been fixed or if it can be an issue?

Cheers,

Johnny

Le mar. 30 janv. 2024 à 20:29, Ingo Klöcker  a écrit :

> On Dienstag, 30. Januar 2024 18:34:46 CET Timothée Ravier wrote:
> > Flathub is now requiring that applications define a "developer_name" tag
> in
> > their metadata (see [1], [2]).
> >
> > What do folks think would be a good value for our application there?
> >
> > Based on the suggestion in the documentation [3], I started making PRs
> [4]
> > [5] [6] [7] for our KDE Apps with "The KDE Community" as the
> > "developer_name" tag.
>
> I grepped my checked out repos and most use either "KDE Community" (9) or
> "The
> KDE Community" (5). lxr.kde.org find 25 times "KDE Community" (some with
> additional names) and 17 times "The KDE Community".
>
>
> https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=%5C%3Cdeveloper_name%5C%3EKDE+Community&_casesensitive=1
>
>
> https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=%5C%3Cdeveloper_name%5C%3EThe+KDE+Commu&_casesensitive=1
>
>
> Regards,
> Ingo
>

Re: [GSoC] org applications open from 22 January - 6 February (deadline at 18:00 UTC)

[Johnny Jazeix]

Thank you Carl for ideas and helping co-administer!

I plan to do the inscription this Saturday (Feb 3rd). If you plan to mentor
an idea but don't have written yet an idea, please ping me so I can count
you as mentor.
Also, if you would like to help co-mentoring, feel free to reach the
mentors who wrote ideas to know if you can help. It would be preferable to
have 2 mentors per idea.

For information, we need to fill a form to register which contain multiple
questions such as how many mentors will we have this year and a link to the
ideas page.
Google will check the ideas page to ensure all the ideas have enough
information and it will be taken in account to accept or reject our
organization so it's important to fill the different fields of the template
(duration...).

Cheers,

Joseph & Johnny

Le mar. 23 janv. 2024 à 14:00, Carl Schwan  a écrit :

> On Tuesday, January 23, 2024 12:22:14 PM CET Joseph P. De Veaugh-Geiss
> wrote:
> > == GSoC 2024 ==
> >
> > It is time to start discussing among your teams what ideas will be great
> > to have for GSoC this year and who is willing to mentor.
> >
> > The organization application period began yesterday and the deadline is
> > on 6 Feb 2024 at 18:00 UTC. We need a wiki page filled with ideas by
> > then! More info can be found at:
> >
> >
> >
> https://opensource.googleblog.com/2024/01/google-summer-of-code-2024-mentor->
> organization-applications-now-open.html
> >
> > Johnny has updated the skeleton wiki ideas page for the 2024 season:
> >
> >https://community.kde.org/GSoC/2024/Ideas
>
> I added two ideas :)
>
> > == Any Co-Admins? ==
> >
> > Are there people willing to help co-admin this year?
> >
> > I (Joseph) will not be able to co-admin as a new KDE Eco project begins
> > in April.
> >
> > Having a team is not only very helpful but it also feels great to see
> > all the work that comes out of your assistance in administering the
> > projects!
>
> I can be a co-admin this year :)
>
> Cheers,
> Carl
>
>
>
>

Re: [GSoC Mentors] GSoC 2024 open for org applications January 22 - February 6

[Johnny Jazeix]

Thanks Valorie,

for info, the required tasks are mostly:
* on each specific period (
https://developers.google.com/open-source/gsoc/timeline), send mails (to
community to recruit people/gather ideas at first, then reminders to
kde-soc and kde-soc-mentors for the next periods);
* create 2 blog posts (one at the beginning of the GSoC and one at the end
- https://dot.kde.org/2023/05/16/kde-google-summer-code-2023 and
https://kde.org/announcements/2023-gsoc-end/, written in markdown);
* be present in case there are issues to be dealt with
(* some administrative tasks but I'll probably handle all of them with the
e.V.)

Cheers,

Johnny

Here are all the mails sent last year to have an idea:
https://mail.kde.org/pipermail/kde-community/2023q1/007429.html
https://mail.kde.org/pipermail/kde-community/2023q1/007499.html
https://mail.kde.org/pipermail/kde-community/2023q1/007524.html
https://mail.kde.org/pipermail/kde-community/2023q2/007605.html
https://mail.kde.org/pipermail/kde-soc/2023-March/001634.html
https://mail.kde.org/pipermail/kde-soc/2023-May/thread.html
https://mail.kde.org/pipermail/kde-soc/2023-July/thread.html
https://mail.kde.org/pipermail/kde-soc/2023-August/thread.html


Le mer. 10 janv. 2024 à 03:35, Valorie Zimmerman <
valorie.zimmer...@gmail.com> a écrit :

> I'm willing to remain on the list of co-admins, but will not be able to be
> more active than I was last year.
>
> Valorie
>
> On Tue, Jan 9, 2024 at 6:32 PM Johnny Jazeix  wrote:
>
>>  Hi,
>>
>> Are there people willing to help co-admin this year? It would be nice to
>> be at least 3 to share the workload.
>>
>> If mentors are interested, there will be a session Thursday (link sent to
>> the mentor list, I've removed it from below as I'm not sure if it's
>> supposed to be mentors only).
>>
>> Main point seem to be: "Starting in 2024 we will have small (~90 hour
>> projects), medium (~175 hr projects) and large (~350 hour) projects
>> available to GSoC contributors. 90 hours projects are optional."
>>
>> I've updated the skeleton wiki page to create the 2024 season:
>> https://community.kde.org/GSoC/2024/Ideas.
>>
>> Please start discussing among your teams what ideas will be great to have
>> this year and who is willing to mentor, as the organisation application
>> date needs to apply between the January 22 - February 6 and we need a wiki
>> page filled with ideas by then.
>> And please don't wait the last moment to fill the page.
>>
>> Cheers,
>>
>> Johnny
>>
>> -- Forwarded message -
>> De : 'sttaylor' via Google Summer of Code Mentors List <
>> google-summer-of-code-mentors-l...@googlegroups.com>
>> Date: ven. 5 janv. 2024 à 00:28
>> Subject: [GSoC Mentors] GSoC Organization Application Info Session
>> January 11th 1700 UTC
>> To: Google Summer of Code Mentors List <
>> google-summer-of-code-mentors-l...@googlegroups.com>
>>
>>
>> Happy New Year!
>>
>> We are very excited to get started on this 20th year of Google Summer of
>> Code!  With Organization applications opening in a few weeks, January 22
>> - February 6, we wanted to host an information session for organizations
>> looking to apply to GSoC as well as for new org admins for veteran orgs so
>> they understand the application process.
>>
>> Date: Thursday, January 11
>>
>> Time: 17:00 - 17:45 UTC
>>
>> GSoC Program Lead, Stephanie Taylor will go through the org application
>> process and discuss the tips to a solid organization application as well as
>> some of the other things to consider when applying as a GSoC organization.
>>
>> There will be plenty of time for Q as well for the last half of the
>> session.
>>
>> Some quick tips for everyone to consider when submitting an Organization
>> application for Google Summer of Code:
>>
>>1.
>>
>>Starting in 2024 we will have small (~90 hour projects), medium (~175
>>hr projects) and large (~350 hour) projects available to GSoC 
>> contributors.
>>Orgs should have medium and large projects available in their Project 
>> Ideas
>>lists. Small project ideas are not required for orgs, but if the smaller
>>size project works for your org they should  be included in your
>>Organization’s Ideas List.
>>2.
>>
>>Reach out to your community members now to ask if they would like to
>>be mentors for the program.
>>
>> Having a thorough and well thought out list of Project Ideas
>> <https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list>
>> is the most 

Fwd: [GSoC Mentors] GSoC 2024 open for org applications January 22 - February 6

[Johnny Jazeix]

 Hi,

Are there people willing to help co-admin this year? It would be nice to be
at least 3 to share the workload.

If mentors are interested, there will be a session Thursday (link sent to
the mentor list, I've removed it from below as I'm not sure if it's
supposed to be mentors only).

Main point seem to be: "Starting in 2024 we will have small (~90 hour
projects), medium (~175 hr projects) and large (~350 hour) projects
available to GSoC contributors. 90 hours projects are optional."

I've updated the skeleton wiki page to create the 2024 season:
https://community.kde.org/GSoC/2024/Ideas.

Please start discussing among your teams what ideas will be great to have
this year and who is willing to mentor, as the organisation application
date needs to apply between the January 22 - February 6 and we need a wiki
page filled with ideas by then.
And please don't wait the last moment to fill the page.

Cheers,

Johnny

-- Forwarded message -
De : 'sttaylor' via Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>
Date: ven. 5 janv. 2024 à 00:28
Subject: [GSoC Mentors] GSoC Organization Application Info Session January
11th 1700 UTC
To: Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>


Happy New Year!

We are very excited to get started on this 20th year of Google Summer of
Code!  With Organization applications opening in a few weeks, January 22 -
February 6, we wanted to host an information session for organizations
looking to apply to GSoC as well as for new org admins for veteran orgs so
they understand the application process.

Date: Thursday, January 11

Time: 17:00 - 17:45 UTC

GSoC Program Lead, Stephanie Taylor will go through the org application
process and discuss the tips to a solid organization application as well as
some of the other things to consider when applying as a GSoC organization.

There will be plenty of time for Q as well for the last half of the
session.

Some quick tips for everyone to consider when submitting an Organization
application for Google Summer of Code:

   1.

   Starting in 2024 we will have small (~90 hour projects), medium (~175 hr
   projects) and large (~350 hour) projects available to GSoC contributors.
   Orgs should have medium and large projects available in their Project Ideas
   lists. Small project ideas are not required for orgs, but if the smaller
   size project works for your org they should  be included in your
   Organization’s Ideas List.
   2.

   Reach out to your community members now to ask if they would like to be
   mentors for the program.

Having a thorough and well thought out list of Project Ideas

is the most important part of your application.

Open source projects can apply  to be
mentoring organizations from January 22 - February 6 at 1800 UTC.

Resources:

Mentor Guide 

Timeline 

FAQs 

Roles and Responsibilities


Marketing Materials
 (slide
deck, flyers)

Videos 


Best,

Stephanie Taylor

GSoC Program Lead

--

Re: We need to remove exec_program() from our Cmake files

[Johnny Jazeix]

Hi,

for the list:
https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=exec_program&_casesensitive=1

Cheers,
Johnny

Le jeu. 26 oct. 2023 à 05:10, Ömer Fadıl USTA  a écrit :

> We need to hurry to remove exec_program() from our cmake files because
> It will be removed with the upcoming CMake's 3.28.0 version which is really
> near to release. ( Just 2 hours ago its rc3 was released ).
> And from a quick search for our repo ( with ripgrep) I have seen that we
> got at least 18 repo using that execure_program(...)
>
> CMake Release Notes :
> https://cmake.org/cmake/help/v3.28/release/3.28.html#deprecated-and-removed-features
>
> ```
> The exec_program()
> 
> command, which has been deprecated since CMake 3.0, has been removed by
> policy CMP0153
> .
> Use the execute_process()
> 
> command instead.
> ```
>
>
> [Sorry for cross post to kde-devel and kde-core-devel ]
>
> Ömer Fadıl Usta
> PGP key : 0xfd11561976b1690b
> about.me/omerusta
>

Re: We need to remove exec_program() from our Cmake files

[Johnny Jazeix]

Hi,

for the list:
https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=exec_program&_casesensitive=1

Cheers,
Johnny

Le jeu. 26 oct. 2023 à 05:10, Ömer Fadıl USTA  a écrit :

> We need to hurry to remove exec_program() from our cmake files because
> It will be removed with the upcoming CMake's 3.28.0 version which is really
> near to release. ( Just 2 hours ago its rc3 was released ).
> And from a quick search for our repo ( with ripgrep) I have seen that we
> got at least 18 repo using that execure_program(...)
>
> CMake Release Notes :
> https://cmake.org/cmake/help/v3.28/release/3.28.html#deprecated-and-removed-features
>
> ```
> The exec_program()
> 
> command, which has been deprecated since CMake 3.0, has been removed by
> policy CMP0153
> .
> Use the execute_process()
> 
> command instead.
> ```
>
>
> [Sorry for cross post to kde-devel and kde-core-devel ]
>
> Ömer Fadıl Usta
> PGP key : 0xfd11561976b1690b
> about.me/omerusta
>

Re: New project to translate videos subtitles

[Johnny Jazeix]

Le lun. 21 août 2023 à 20:48, Ben Cooksley  a écrit :
>
> On Mon, Aug 21, 2023 at 12:00 AM Johnny Jazeix  wrote:
>>
>> Hi,
>
>
> Hi Johnny,
>
>>
>>
>> Inspired by the accessibility goal, Promo had the idea of including
>> subtitles and closed captions for videos for several KDE projects
>> (Akademy interviews, GCompris videos like
>> https://tube.kockatoo.org/w/symxHCzUj9TA7LZoZagD9c...).
>>
>> I've created a repository which handles the conversion from subtitles
>> <=> po files for translators using KDE scripts
>> (https://invent.kde.org/jjazeix/srt2po) and Translate Toolkit.
>> There is also a script to upload the subtitles to the KDE peertube instance.
>>
>> There could be several issues with translating only the text but I
>> still think it's worth it to be able to translate them using the usual
>> KDE workflow:
>> * if we want to display some lines longer because the translated text
>> takes more time to read;
>> * if we want to add extra texts at different times.
>> In order to workaround these issues, the project will also allow
>> translator to directly write the srt files instead of passing by a po
>> file.
>> All the srt files will be centralised here, which will avoid
>> translators to look for them.
>>
>> In which gitlab group would it be better to create this repository and
>> what would be the process to create it? Accessibility ou Utilities
>> seem good to me but as it will contain more data than scripts/code,
>> maybe there is a better place for it.
>
>
> This isn't something that fits terribly well within our existing groupings, 
> especially given it is mostly promotional content.
>
> The tooling itself that supports this should go to SDK I would say, as this 
> is something that only a developer/translator/etc would use (never an actual 
> user).
>
> In the absence of anything else, websites/ works well for the actual content 
> itself given this will end up attached to videos we publish online.
>

That would be good for me. There is actually one script (to upload to
peertube). At some point, it would be nice to have the same for
YouTube. The conversion between srt and po is done via an existing
toolkit so if it fits the needs, there won't be any more scripts. Is
there an existing SDK repo that could welcome these scripts?

The srt files can go to a new Websites repository, that is ok for me.
I'll wait until the end of the week to create a sysadmin ticket in
case there is more to discuss before creating it.

Thanks Albert and Ben,

Johnny

> Cheers,
> Ben
>
>>
>>
>> Cheers,
>> Johnny

New project to translate videos subtitles

[Johnny Jazeix]

Hi,

Inspired by the accessibility goal, Promo had the idea of including
subtitles and closed captions for videos for several KDE projects
(Akademy interviews, GCompris videos like
https://tube.kockatoo.org/w/symxHCzUj9TA7LZoZagD9c...).

I've created a repository which handles the conversion from subtitles
<=> po files for translators using KDE scripts
(https://invent.kde.org/jjazeix/srt2po) and Translate Toolkit.
There is also a script to upload the subtitles to the KDE peertube instance.

There could be several issues with translating only the text but I
still think it's worth it to be able to translate them using the usual
KDE workflow:
* if we want to display some lines longer because the translated text
takes more time to read;
* if we want to add extra texts at different times.
In order to workaround these issues, the project will also allow
translator to directly write the srt files instead of passing by a po
file.
All the srt files will be centralised here, which will avoid
translators to look for them.

In which gitlab group would it be better to create this repository and
what would be the process to create it? Accessibility ou Utilities
seem good to me but as it will contain more data than scripts/code,
maybe there is a better place for it.

Cheers,
Johnny

Re: KDE Gear projects with failing CI (release/23.08) (8 August 2023)

[Johnny Jazeix]

This commit must be cherry-picked:
https://invent.kde.org/system/partitionmanager/-/blob/master/.reuse/dep5?ref_type=heads.

I'm doing it

Le mer. 9 août 2023 à 11:20, Carl Schwan  a écrit :
>
> On Wed, Aug 9, 2023, at 9:44 AM, Johnny Jazeix wrote:
>
> Le mar. 8 août 2023 à 23:24, Albert Astals Cid  a écrit :
> >
> > Please work on fixing them, otherwise i will eventually remove the failing 
> > CI
> > jobs, it is very important that CI is passing for multiple reasons.
> >
> > This is the first release/23.08 report
> >
> > = REUSE FAILURES (3 repos) =
> >
> > partitionmanager:
> >  * https://invent.kde.org/system/partitionmanager/-/pipelines/456102
> >
>
> MR done by Carl:
> https://invent.kde.org/system/partitionmanager/-/merge_requests/32,
> will need to be cherry-picked in release/23.08 once merged.
>
>
> Unfortunately the reuse failure in release/23.08 looks more serious
> https://invent.kde.org/system/partitionmanager/-/jobs/1107615
>
> No idea why reuse it completely not working on that branch
>
> > kpmcore:
> >  * https://invent.kde.org/system/kpmcore/-/pipelines/456103
> >
>
> I've cherry-picked the fix in master, it builds fine now
>
> > kweather:
> >  * https://invent.kde.org/utilities/kweather/-/pipelines/456125
> >
>
> I've cherry-picked the fix in master, now and also the one needed for
> Flatpak (runtime upgrade)
>
> >
> > = FLATPAK FAILURES (1 repo) =
> >
> > calindori:
> >  * https://invent.kde.org/plasma-mobile/calindori/-/jobs/1106264
> >   * I think it should be compiling kcalendarcore from a tag, not a branch
> >
>
> Carl fixed it!
>
> Cheers,
>
> Johnny
>
>

Re: KDE Gear projects with failing CI (release/23.08) (8 August 2023)

[Johnny Jazeix]

Le mar. 8 août 2023 à 23:24, Albert Astals Cid  a écrit :
>
> Please work on fixing them, otherwise i will eventually remove the failing CI
> jobs, it is very important that CI is passing for multiple reasons.
>
> This is the first release/23.08 report
>
> = REUSE FAILURES (3 repos) =
>
> partitionmanager:
>  * https://invent.kde.org/system/partitionmanager/-/pipelines/456102
>

MR done by Carl:
https://invent.kde.org/system/partitionmanager/-/merge_requests/32,
will need to be cherry-picked in release/23.08 once merged.

> kpmcore:
>  * https://invent.kde.org/system/kpmcore/-/pipelines/456103
>

I've cherry-picked the fix in master, it builds fine now

> kweather:
>  * https://invent.kde.org/utilities/kweather/-/pipelines/456125
>

I've cherry-picked the fix in master, now and also the one needed for
Flatpak (runtime upgrade)

>
> = FLATPAK FAILURES (1 repo) =
>
> calindori:
>  * https://invent.kde.org/plasma-mobile/calindori/-/jobs/1106264
>   * I think it should be compiling kcalendarcore from a tag, not a branch
>

Carl fixed it!

Cheers,

Johnny

Re: [kdiff3] [Bug 470221] New: KDiff3 in winget store still at version 1.9.6

[Johnny Jazeix]

It seems to be packages created by the winget community, not KDE:
https://github.com/microsoft/winget-pkgs/pulls?q=is%3Apr+Kdiff3+is%3Aclosed
Maybe we should suggest the person to open a bug there instead (looking at
the issues, there are "Package-Update" tags)?

Cheers,

Johnny

Le mer. 24 mai 2023 à 19:03, Michael Reeves  a écrit :

> Some other than myself needs to resolve this but I have no idea who.
>
> -- Forwarded message -
> From: 石庭豐 
> Date: Wed, May 24, 2023 at 12:25 PM
> Subject: [kdiff3] [Bug 470221] New: KDiff3 in winget store still at
> version 1.9.6
> To: 
>
>
> https://bugs.kde.org/show_bug.cgi?id=470221
>
> Bug ID: 470221
>Summary: KDiff3 in winget store still at version 1.9.6
> Classification: Applications
>Product: kdiff3
>Version: 1.9.6
>   Platform: Microsoft Windows
> OS: Microsoft Windows
> Status: REPORTED
>   Severity: grave
>   Priority: NOR
>  Component: application
>   Assignee: reeves...@gmail.com
>   Reporter: lapsap7+...@gmail.com
>   Target Milestone: ---
>
> STEPS TO REPRODUCE
> 1. Run "winget install -e --id KDE.KDiff3" in PowerShell
>
> OBSERVED RESULT
> Version 1.9.6 is installed
>
> EXPECTED RESULT
> Version 1.10.4 is installed
>
> SOFTWARE/OS VERSIONS
> Windows: Windows 10 (but unrelated to this issue)
>
> ADDITIONAL INFORMATION
> Question:
>   Is KDiff3 inside *winget store* still maintained?
>
> If it's not maintained, may I suggest you to *delete* everything about
> KDiff3
> in winget store.  In this way, people would be forced to download the
> latest
> version from your web site.  This could eliminate a lot of potential
> problems.
>
> However, if it's still maintained, please fix the issue.  Thanks in
> advance.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
>

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Johnny Jazeix]

Hi,
Le dim. 21 mai 2023 à 11:15, Ben Cooksley  a écrit :

> Hi all,
>
> As many of you will undoubtedly be aware, we currently have a bit of a
> hybrid approach with our use of GitLab, with some projects/areas still
> making use of Phabricator as they await the final import of these tasks
> across to GitLab.
>
> That time has now arrived, as Phabricator is long since unmaintained and
> needs to be retired.
>
> The only question is how this is best structured.
>
> My thinking on this had been to establish a mapping of Phabricator project
> to Gitlab project (with some Gitlab projects possibly receiving multiple
> Phabricator projects). Where necessary we would create groups/projects
> under teams/ on invent.kde.org to house these, otherwise they'd be
> imported into the mainline projects.
>
> For those projects currently using GitLab as a task tracking tool, any
> feedback you have on this would also be welcome.
>
> In terms of the migration, we'd be looking to retain as much information
> as possible, however things like the precise column a task has on a
> workboard would likely be lost. The actual content of the task including
> details such as time and authorship, along with any comments would be
> retained though.
>
>
Would there be a way to convert some columns as labels? For example, we
have columns "Junior Jobs" that would be nice to have as a label.
Also, some phabricator tasks have hierarchy, is there an equivalent in
gitlab? There are tasks in gitlab too but I'm not sure it is always the
equivalent.

Cheers,

Johnny


> Thoughts?
>
> Thanks,
> Ben
>

Re: Flatpak Manifest Licensing

[Johnny Jazeix]

Le ven. 19 mai 2023 à 02:27, Justin Zobel  a écrit :

> Hey Everyone,
>
> As Binary Factory is to be shut down soon we are moving the Flatpak
> manifests to their individual GitLab repositories.
>
> Most of this is fairly simple, however, some GitLab repositories have
> enabled reuse linting (which is great). The Flatpak manifests I have
> come across so far have not had any licensing information included. This
> email is just to start a discussion about what everyone's thoughts are
> about which license to apply for them.
>
> The GitLab CI files are licensed as CC0-1.0 and I'm thinking that this
> might be a suitable license as the Flatpak manifest files are simply
> text files.
> # SPDX-FileCopyrightText: None
> # SPDX-License-Identifier: CC0-1.0
>
> Let me know your thoughts.
>
> Justin
>

Hi,

is this on what Neelaksh worked during SoK? For GCompris, he added it with
CopyrightText: None and CC0-1.0 like you say and it's fine with us:
https://invent.kde.org/education/gcompris/-/commit/3cb28877c95a84e2c1d8062e2fb6436ef3953024

Cheers,
Johnny

Re: developer account set up

[Johnny Jazeix]

Hi,
Le dim. 7 mai 2023 à 17:54, Konstantin Kharlamov  a
écrit :

> On Sun, 2023-05-07 at 17:21 +0200, Nate Graham wrote:
> > There's also no reason anymore why they need to use a work branch in the
> > main repo; a fork works just fine. I do nearly all of my development
> > using personal forks; it's a 100% supported first-class citizen
> experience.
>
> +1
>
>
Ok for me to go with forks for GSoC but as Ben said, we probably need to
find something about abandoned forks.

I remember when we were integrating Gitlab at work, people for some reason
> were
> attempting to create branches in the upstream repo rather than on their own
> fork. Had to do some explanation that this isn't the way to go, because
> after an
> year of such workflow upstream will end up with hundreds if not thousands
> of
> abandoned branches that serve no purpose, and who's gonna clean that up
> 路‍♂️
> Especially given that people may come and go, and so in some cases you
> wouldn't
> even find an author of a branch (and in some cases it's hard to even
> figure out
> who could be the author in the first place).
>

The issues you mentioned are the same with forks. Instead of having
abandoned branches in the main repo where maintainers could know if they
are active or not, we will have abandoned branches in abandoned
repositories without MR to know they exist and they would need to be
cleaned.

Cheers,
Johnny

Re: developer account set up

[Johnny Jazeix]

Le dim. 7 mai 2023 à 11:22, Nate Graham  a écrit :

> -Utarsh
>
> It might be worth re-thinking this policy now that we use GitLab. People
> don't need a developer account to fully contribute anymore.
>
> Nate
>
>
We usually recommend contributors to create branches in the main repository
(work/gsoc/...). Is it possible without a developer account?

Johnny


>
> On 5/7/23 09:41, Johnny Jazeix wrote:
> >
> >
> > Le sam. 6 mai 2023 à 23:31, Nate Graham  > <mailto:n...@kde.org>> a écrit :
> >
> > Hello Utkarsh,
> >
> > You don't need a developer *account* to start contributing, and in
> fact
> > you can't have one until you've made a number of contributions
> > already. :)
> >
> > If you're looking for information about starting the process of
> > contributing with code, we have a bunch of documentation at
> > https://community.kde.org/Get_Involved/development
> > <https://community.kde.org/Get_Involved/development>.
> >
> >
> > Best of luck!
> >
> > Nate
> >
> >
> > On 5/6/23 20:42, Utkarsh Kumar wrote:
> >  > Hlw, I am Utkarsh Kumar and I want to need help creating a
> developer
> >  > account setup. so please can someone suggest to me the steps I
> > need to
> >  > follow to create a developer account?
> >
> >
> > Hi Nate,
> > Utkarsh has been selected for GSoC to work on digiKam and it's a
> > prerequisite to create a developer account do in the community bonding
> > period.
> > Cheers,
> >
> > Johnny
>

Re: developer account set up

[Johnny Jazeix]

Le sam. 6 mai 2023 à 23:31, Nate Graham  a écrit :

> Hello Utkarsh,
>
> You don't need a developer *account* to start contributing, and in fact
> you can't have one until you've made a number of contributions already. :)
>
> If you're looking for information about starting the process of
> contributing with code, we have a bunch of documentation at
> https://community.kde.org/Get_Involved/development.
>
>
> Best of luck!
>
> Nate
>
>
> On 5/6/23 20:42, Utkarsh Kumar wrote:
> > Hlw, I am Utkarsh Kumar and I want to need help creating a developer
> > account setup. so please can someone suggest to me the steps I need to
> > follow to create a developer account?
>

Hi Nate,
Utkarsh has been selected for GSoC to work on digiKam and it's a
prerequisite to create a developer account do in the community bonding
period.
Cheers,

Johnny

Re: GSoC program

[Johnny Jazeix]

Hi Abanoub,

I would suggest you to go to the Kalendar room in https://webchat.kde.org/
directly to discuss with the developers as soon as you can.
To create an account, you can follow the page
https://community.kde.org/Matrix.

Note that you'll have to discuss the idea, how you plan to implement it in
a proposal that you have to submit to the
https://summerofcode.withgoogle.com/ website before the April 4th in order
to have a chance to get selected for the idea.

Cheers,

Johnny

Le ven. 31 mars 2023 à 19:47, Abanoub Younan  a
écrit :

> Hi, I am Abanoub a 4th-year computer science student, I have a good
> experience in c++ from competitive programming and I am very interested to
> work on (A calendar invitation) project, but I am new to open-source
> contribution I don't know if I am a suitable for developing this idea or
> not, but I am ready to learn and develop my-self to can finish this idea,
> Can you help me to know what I need to be suitable for developing this idea?
> Thanks in advance
>

Re: MR Gardening - A discussion, please leave your input!

[Johnny Jazeix]

Le mar. 7 mars 2023 à 00:15, AnnoyingRains  a
écrit :

> > We should never close a MR automatically. Only a maintainer of a project
> or the author itself should close a MR.
>
> I agree with not closing MRs automatically. As I stated in my original
> message, we are no longer planning on doing that, it's not helpful and
> is only destructive.
> The decision to close an MR will be left with the specific project's
> maintainers and the person who opened the MR.
>
> > The decision if a MR should be closed or not is often depending on a
> context (e.g. a MR required another MR to be merged first
> > and it is taking more time than expected, the author is busy with other
> things but will eventually come back to it, ...)
> > and a script is unable to see this.
>
> I would also argue that humans that are not a maintainer of that
> specific project should not close an MR for similar reasons. There is
> a lot here that the gardening team would need to know about every
> project
>
> > for GCompris, we don't have a lot of MR and even if some are old, we
> still plan to take over them at some point (we know which ones are
> unmaintained) so I think it's preferable to not add messages.
>
> We can exclude Gcompris if you feel it is needed, but I am unsure how
> labeling MRs as stale and reminding authors wouldn't be preferable.
>
>
Hi,

It will be considered as noise and ignored. We have two use cases:
* Either the person is following and if a MR is stalling it's because
maintainers don't have enough time to handle it now.
* Either the person is no more following (for multiple reasons) and
maintainers already know it and they plan to handle the MR later.

In both cases, no action will be taken.

As there are not a lot of MR (6), it's an amount we can handle it by
ourselves.
I think what you propose is more important and has more values when there a
lot of MR opened and it's more complicated to handle them (or more
maintainers).²

Cheers,

Johnny


> > but this should probably be done manually
>
> We are planning on doing this manually until all of the issues have
> been ironed out perfectly and we know a foolproof way to ensure
> nothing is ever poked that shouldn't be, which may never happen.
> We will open another discussion before automating anything, due to the
> potential disaster a bug could cause.
>
> > "Hi, I really like this work, do you intent to continue working
> > on it or can I take over" than a generic message that feels fake.
>
> This is great, but not exactly what this inititive is about.
> This is more for reminding people that the MR exists (even had one
> case of "oh! I forgot I made this MR" in my small scale test!), and
> labeling MRs so that contributors feel more free to request taking
> over the project.
> Basically, we cannot really take over every stale MR in the entirety of
> KDE.
>
> - Kye Potter, KDE Gardening
>
>
> On Tue, Mar 7, 2023 at 9:39 AM Albert Astals Cid  wrote:
> >
> > El dilluns, 6 de març de 2023, a les 15:18:42 (CET), Carl Schwan va
> escriure:
> > > Hi,
> > >
> > > We should never close a MR automatically. Only a maintainer of a
> project
> > > or the author itself should close a MR. The decision if a MR should be
> > > closed or not is often depending on a context (e.g. a MR required
> another
> > > MR to be merged first and it is taking more time than expected, the
> > > author is busy with other things but will eventually come back to it,
> ...)
> > > and a script is unable to see this.
> > >
> > > I do not mind poking people semi-regularly (every 6 months or so), but
> again
> > > this should probably be done manually and with a small personalized
> message
> > > for example: "Hi, I really like this work, do you intent to continue
> > > working on it or can I take over" than a generic message that feels
> fake.
> > >
> > > I really hate communicating with robots instead of with humans and I
> really
> > > see the trends of trying to automatize all our interaction with dumb
> robots
> > > and chat bots in our society really worrying.
> > >
> > > If we want to automatize, we should instead try to list the stale MRs
> and
> > > maybe send the list to the mailing list once a month so that people are
> > > reminded about them and take a look at which one they may be able to
> unlock.
> >
> > We already have that, they get posted to
> >  https://invent.kde.org/teams/gardening/gitlab/-/issues
> > weekly.
> >
> > What i forgot is what i did to be notified of it by email ^_^
> >
> > Cheers,
> >   Albert
> >
> > >
> > > Cheers,
> > > Carl
> > >
> > >
> > > --- Original Message ---
> > >
> > > Le dimanche 5 mars 2023 à 11:13 AM, AnnoyingRains <
> annoyingra...@gmail.com>
> > a écrit :
> > > > For a short amount of time now, there have been some small-scale
> > > > trials of replying to old MRs with a reminder, and suggesting that
> the
> > > > author closes the MR if it is either no longer needed or if it needs
> > > > more work and the author does not have time for it.
> 

Re: MR Gardening - A discussion, please leave your input!

[Johnny Jazeix]

Le mar. 7 mars 2023 à 00:15, AnnoyingRains  a
écrit :

> > We should never close a MR automatically. Only a maintainer of a project
> or the author itself should close a MR.
>
> I agree with not closing MRs automatically. As I stated in my original
> message, we are no longer planning on doing that, it's not helpful and
> is only destructive.
> The decision to close an MR will be left with the specific project's
> maintainers and the person who opened the MR.
>
> > The decision if a MR should be closed or not is often depending on a
> context (e.g. a MR required another MR to be merged first
> > and it is taking more time than expected, the author is busy with other
> things but will eventually come back to it, ...)
> > and a script is unable to see this.
>
> I would also argue that humans that are not a maintainer of that
> specific project should not close an MR for similar reasons. There is
> a lot here that the gardening team would need to know about every
> project
>
> > for GCompris, we don't have a lot of MR and even if some are old, we
> still plan to take over them at some point (we know which ones are
> unmaintained) so I think it's preferable to not add messages.
>
> We can exclude Gcompris if you feel it is needed, but I am unsure how
> labeling MRs as stale and reminding authors wouldn't be preferable.
>
>
Hi,

It will be considered as noise and ignored. We have two use cases:
* Either the person is following and if a MR is stalling it's because
maintainers don't have enough time to handle it now.
* Either the person is no more following (for multiple reasons) and
maintainers already know it and they plan to handle the MR later.

In both cases, no action will be taken.

As there are not a lot of MR (6), it's an amount we can handle it by
ourselves.
I think what you propose is more important and has more values when there a
lot of MR opened and it's more complicated to handle them (or more
maintainers).²

Cheers,

Johnny


> > but this should probably be done manually
>
> We are planning on doing this manually until all of the issues have
> been ironed out perfectly and we know a foolproof way to ensure
> nothing is ever poked that shouldn't be, which may never happen.
> We will open another discussion before automating anything, due to the
> potential disaster a bug could cause.
>
> > "Hi, I really like this work, do you intent to continue working
> > on it or can I take over" than a generic message that feels fake.
>
> This is great, but not exactly what this inititive is about.
> This is more for reminding people that the MR exists (even had one
> case of "oh! I forgot I made this MR" in my small scale test!), and
> labeling MRs so that contributors feel more free to request taking
> over the project.
> Basically, we cannot really take over every stale MR in the entirety of
> KDE.
>
> - Kye Potter, KDE Gardening
>
>
> On Tue, Mar 7, 2023 at 9:39 AM Albert Astals Cid  wrote:
> >
> > El dilluns, 6 de març de 2023, a les 15:18:42 (CET), Carl Schwan va
> escriure:
> > > Hi,
> > >
> > > We should never close a MR automatically. Only a maintainer of a
> project
> > > or the author itself should close a MR. The decision if a MR should be
> > > closed or not is often depending on a context (e.g. a MR required
> another
> > > MR to be merged first and it is taking more time than expected, the
> > > author is busy with other things but will eventually come back to it,
> ...)
> > > and a script is unable to see this.
> > >
> > > I do not mind poking people semi-regularly (every 6 months or so), but
> again
> > > this should probably be done manually and with a small personalized
> message
> > > for example: "Hi, I really like this work, do you intent to continue
> > > working on it or can I take over" than a generic message that feels
> fake.
> > >
> > > I really hate communicating with robots instead of with humans and I
> really
> > > see the trends of trying to automatize all our interaction with dumb
> robots
> > > and chat bots in our society really worrying.
> > >
> > > If we want to automatize, we should instead try to list the stale MRs
> and
> > > maybe send the list to the mailing list once a month so that people are
> > > reminded about them and take a look at which one they may be able to
> unlock.
> >
> > We already have that, they get posted to
> >  https://invent.kde.org/teams/gardening/gitlab/-/issues
> > weekly.
> >
> > What i forgot is what i did to be notified of it by email ^_^
> >
> > Cheers,
> >   Albert
> >
> > >
> > > Cheers,
> > > Carl
> > >
> > >
> > > --- Original Message ---
> > >
> > > Le dimanche 5 mars 2023 à 11:13 AM, AnnoyingRains <
> annoyingra...@gmail.com>
> > a écrit :
> > > > For a short amount of time now, there have been some small-scale
> > > > trials of replying to old MRs with a reminder, and suggesting that
> the
> > > > author closes the MR if it is either no longer needed or if it needs
> > > > more work and the author does not have time for it.
> 

Re: MR Gardening - A discussion, please leave your input!

[Johnny Jazeix]

Hi,

for GCompris, we don't have a lot of MR and even if some are old, we still
plan to take over them at some point (we know which ones are unmaintained)
so I think it's preferable to not add messages.

In a general manner, as said by Carl, MR should not be closed automatically.

Cheers,

Johnny

Le dim. 5 mars 2023 à 11:14, AnnoyingRains  a
écrit :

> For a short amount of time now, there have been some small-scale
> trials of replying to old MRs with a reminder, and suggesting that the
> author closes the MR if it is either no longer needed or if it needs
> more work and the author does not have time for it.
>
> This has appeared to have a positive impact on the state of KDE
> software from this (albeit limited) trial. Some MRs have had renewed
> interest, others have admitted that they had forgotten that the MR
> even existed.
>
> We did consider closing MRs if there was no activity after our ping
> message. **We are no longer planning on doing this**, as it is more
> destructive than helpful. All decisions on if a MR should be closed
> will be left with the maintainers and the person who opened the MR.
>
> So, we need a proper discussion about this, should we send these
> reminder messages at all? If so, how old should an MR be before
> sending this reminder? Should closing the MR even be suggested in the
> message?
>
> If your specific project does not play nicely with this programme,
> please let us know and we can add it to the list of exclusions on our
> KDE Community page.
>
> I need your input,
> - Kye Potter, KDE Gardening
>

Re: MR Gardening - A discussion, please leave your input!

[Johnny Jazeix]

Hi,

for GCompris, we don't have a lot of MR and even if some are old, we still
plan to take over them at some point (we know which ones are unmaintained)
so I think it's preferable to not add messages.

In a general manner, as said by Carl, MR should not be closed automatically.

Cheers,

Johnny

Le dim. 5 mars 2023 à 11:14, AnnoyingRains  a
écrit :

> For a short amount of time now, there have been some small-scale
> trials of replying to old MRs with a reminder, and suggesting that the
> author closes the MR if it is either no longer needed or if it needs
> more work and the author does not have time for it.
>
> This has appeared to have a positive impact on the state of KDE
> software from this (albeit limited) trial. Some MRs have had renewed
> interest, others have admitted that they had forgotten that the MR
> even existed.
>
> We did consider closing MRs if there was no activity after our ping
> message. **We are no longer planning on doing this**, as it is more
> destructive than helpful. All decisions on if a MR should be closed
> will be left with the maintainers and the person who opened the MR.
>
> So, we need a proper discussion about this, should we send these
> reminder messages at all? If so, how old should an MR be before
> sending this reminder? Should closing the MR even be suggested in the
> message?
>
> If your specific project does not play nicely with this programme,
> please let us know and we can add it to the list of exclusions on our
> KDE Community page.
>
> I need your input,
> - Kye Potter, KDE Gardening
>

Fwd: [GSoC Mentors] GSoC Org Applications are now open (and close Feb 7 1800 UTC)

[Johnny Jazeix]

Hi,

a kind reminder: we need to fill an application in the GSoC website before
the 7th with the ideas page (https://community.kde.org/GSoC/2023/Ideas) and
the mentors count.
For now, we have 5 mentors (and 8 ideas) and we have to write a number in
our application before the 7th (so let's make the deadline this Sunday).
If we only write 5 mentors and we decide of more ideas later, I'm not sure
Google will provide us more slots.

If you want to mentor please reach your team and write an idea with mentors
in the ideas page before the 5th so we can have a clean filled page when
Google checks on it to provide us the number of slots we will ask.

Cheers,

Johnny

-- Forwarded message -
De : 'sttaylor' via Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>
Date: mar. 24 janv. 2023 à 00:58
Subject: [GSoC Mentors] GSoC Org Applications are now open (and close Feb 7
1800 UTC)
To: Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>


Hi all,

GSoC 2023 Organization Applications are now open at g.co/gsoc! You can
scroll to the middle of the homepage and click the ‘Register your
organization’ button and start registration.

For those orgs that applied in 2022 your information (org profile, org
details) are still in the GSoC webapp so you will have a super quick
application for 2023. But please don’t wait until the final hours to submit
your application, all org applications are due by Tuesday, February 7 at
1800 UTC.
...
Best,

Stephanie Taylor

GSoC Program Lead

-- 
You received this message because you are subscribed to the Google Groups
"Google Summer of Code Mentors List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-mentors-list+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-summer-of-code-mentors-list/4bd620f0-9dfe-4733-95ec-31a71a5d8db5n%40googlegroups.com

.

Re: GSoC 2023

[Johnny Jazeix]

Hi and welcome!

Do you have a software in particular you'd like to contribute? GSoC is a
program to help new contributors integrate an open source community and
work on softwares they like. So first to know is which softwares in KDE you
like and want to contribute on.
Then, you will need to discuss with the team to know if there are subjects
that you could work on during GSoC.
To answer your question about junior jobs, you can find some in
https://bugs.kde.org/buglist.cgi?quicksearch=JJ or
https://bugs.kde.org/buglist.cgi?quicksearch=Junior.
For now, we have few subjects written in
https://community.kde.org/GSoC/2023/Ideas but you should not choose one if
it does not interest you.

Cheers,

Johnny

Le jeu. 26 janv. 2023 à 09:42, Tejus Khandelwal  a
écrit :

> Hi everyone,
>
> I am Tejus Khandelwal, a 2nd year UG student at the Indian Institute of
> Technology Kanpur. I have previously worked in C, C++, and Python and am
> enthusiastic about learning new things. I wish to contribute to KDE in GSoC
> 2023 and need help beginning.
>
> I would be highly grateful if someone could point out some
> beginner-friendly issues to help me get started.
>
> Thanks.
>
>

Re: [GSoC Mentors] GSoC 2023 open for org applications January 23 - February 7

[Johnny Jazeix]

Hi,

org applications start tomorrow and there is no idea at all in the page (
https://community.kde.org/GSoC/2023/Ideas). Are we interested to
participate to GSoC this year?

Cheers,

Johnny

Le mar. 10 janv. 2023 à 21:58, Johnny Jazeix  a écrit :

> Hi,
>
> Are there people willing to help co-admin this year? For now, we are 3
> admins so one more would be nice to share the workload.
>
> I've updated the skeleton wiki page to create the 2023 season:
> https://community.kde.org/GSoC/2023/Ideas.
>
> Please start discussing among your teams what ideas will be great to have
> this year and who is willing to mentor, as the organisation application
> date needs to apply between the January 23 - Feb 7, 2023 and we need a wiki
> page filled with ideas by then.
>
> More info can be found at
> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>
> Cheers,
>
> Johnny
>
> -- Forwarded message -
> De : 'sttaylor' via Google Summer of Code Mentors List <
> google-summer-of-code-mentors-l...@googlegroups.com>
> Date: lun. 14 nov. 2022 à 23:51
> Subject: [GSoC Mentors] GSoC 2023 open for org applications January 23 -
> February 7
> To: Google Summer of Code Mentors List <
> google-summer-of-code-mentors-l...@googlegroups.com>
>
>
> We’re pleased to announce
> <https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html>
> the Google Summer of Code 2023 program and timeline
> <https://developers.google.com/open-source/gsoc/timeline>. GSoC Org
> Applications are open from January 23 - Feb 7, 2023.
>
> In 2022 we implemented our biggest changes to the program in its 18 year
> history and had an overwhelmingly positive response to the changes
> (extended timelines, medium and large size projects and opening eligibility
> beyond students) so we are keeping the changes as we go into 2023 with a
> couple of minor tweaks.
>
>1.
>
>Per the conversation on the mentor list this summer, we are expanding
>the eligibility to include students and beginners to open source
>development. There was some confusion about students who might have
>some experience in open source so we have fixed that with this new
>eligibility rule.
>2.
>
>The other change is that we are back to allowing a person to be
>accepted as a GSoC Contributor up to 2 times (regardless of when their
>first GSoC acceptance was). This assumes they could still be considered a
>beginner - ie. they didn’t participate as a GSoC student in 2015 and have
>been actively involved in open source development since then and want to
>come back 8 years later to be a GSoC Contributor.
>3.
>
>We have shifted the timeline to start a couple of weeks earlier, so
>that the program wraps up for the standard 12 week projects by early
>September which is generally what the schedule looked like for many of the
>past 18 years.
>
> *Spreading the word about GSoC*
>
> The GSoC 2023 flyer
> <https://developers.google.com/open-source/gsoc/resources/downloads/GSoC2023Flyer.pdf>
> and the new, more colorful and exciting GSoC 2023 slides
> <https://developers.google.com/open-source/gsoc/resources/downloads/GSoC2023Presentation.pdf>
> are available for you to use in any presentations you wish to do about
> GSoC. We need your help to spread the word amongst your circles.
>
> We encourage you to explore our resources
> <https://developers.google.com/open-source/gsoc/resources/>, timeline
> <https://developers.google.com/open-source/gsoc/timeline>, the 
> Contributor/Student
> Guide <https://google.github.io/gsocguides/student/>and Mentor Guide
> <https://google.github.io/gsocguides/mentor/> as well.
>
>
> *Have a group you think GSoC Program Admins should reach out to?*
>
> Diversity in open source communities is vital to the health of our
> communities. Please spread the word about GSoC to communities in your
> country or in your network particularly those that reach underrepresented
> groups in open source. If you have a suggestion for a group you think the
> GSoC team should add to our list of contacts that we send out emails to
> about the program early in the new year, or if you have a group that you
> think would be a good opportunity for GSoC Administrators to give a talk
> about GSoC please email us at gsoc-supp...@google.com with their details
> (email and contact person if you have one available).
>
>
> *See you at FOSDEM!*
>
> As Chris mentioned in the GSoC 22 Mentor Summit a couple of weeks ago, our
> team is very excited to attend FOSDEM in Brussels in 2023. We will send
> more details in Ja

Fwd: [GSoC Mentors] GSoC 2023 open for org applications January 23 - February 7

[Johnny Jazeix]

 Hi,

Are there people willing to help co-admin this year? For now, we are 3
admins so one more would be nice to share the workload.

I've updated the skeleton wiki page to create the 2023 season:
https://community.kde.org/GSoC/2023/Ideas.

Please start discussing among your teams what ideas will be great to have
this year and who is willing to mentor, as the organisation application
date needs to apply between the January 23 - Feb 7, 2023 and we need a wiki
page filled with ideas by then.

More info can be found at
https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html

Cheers,

Johnny

-- Forwarded message -
De : 'sttaylor' via Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>
Date: lun. 14 nov. 2022 à 23:51
Subject: [GSoC Mentors] GSoC 2023 open for org applications January 23 -
February 7
To: Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>


We’re pleased to announce

the Google Summer of Code 2023 program and timeline
. GSoC Org
Applications are open from January 23 - Feb 7, 2023.

In 2022 we implemented our biggest changes to the program in its 18 year
history and had an overwhelmingly positive response to the changes
(extended timelines, medium and large size projects and opening eligibility
beyond students) so we are keeping the changes as we go into 2023 with a
couple of minor tweaks.

   1.

   Per the conversation on the mentor list this summer, we are expanding
   the eligibility to include students and beginners to open source
   development. There was some confusion about students who might have some
   experience in open source so we have fixed that with this new eligibility
   rule.
   2.

   The other change is that we are back to allowing a person to be accepted
   as a GSoC Contributor up to 2 times (regardless of when their first GSoC
   acceptance was). This assumes they could still be considered a beginner -
   ie. they didn’t participate as a GSoC student in 2015 and have been
   actively involved in open source development since then and want to come
   back 8 years later to be a GSoC Contributor.
   3.

   We have shifted the timeline to start a couple of weeks earlier, so that
   the program wraps up for the standard 12 week projects by early September
   which is generally what the schedule looked like for many of the past 18
   years.

*Spreading the word about GSoC*

The GSoC 2023 flyer

and the new, more colorful and exciting GSoC 2023 slides

are available for you to use in any presentations you wish to do about
GSoC. We need your help to spread the word amongst your circles.

We encourage you to explore our resources
, timeline
, the
Contributor/Student
Guide and Mentor Guide
 as well.


*Have a group you think GSoC Program Admins should reach out to?*

Diversity in open source communities is vital to the health of our
communities. Please spread the word about GSoC to communities in your
country or in your network particularly those that reach underrepresented
groups in open source. If you have a suggestion for a group you think the
GSoC team should add to our list of contacts that we send out emails to
about the program early in the new year, or if you have a group that you
think would be a good opportunity for GSoC Administrators to give a talk
about GSoC please email us at gsoc-supp...@google.com with their details
(email and contact person if you have one available).


*See you at FOSDEM!*

As Chris mentioned in the GSoC 22 Mentor Summit a couple of weeks ago, our
team is very excited to attend FOSDEM in Brussels in 2023. We will send
more details in January but we are in the early stages of planning a GSoC
Meetup for Saturday night during FOSDEM as we have done in previous years.
Looking forward to seeing many of you in Brussels in February!


*GSoC Videos*

We have been busy working with our mentors and GSoC contributors to create
new GSoC videos as they are a popular medium for new folks to learn about
GSoC.

A HUGE thank you to our mentors that helped with the new ‘Introduction to
Google Summer of Code’ video  (Adrian,
Benjamin, Ann, Rāzvan,  Meenakshi, Srishti and Gabriel). And thanks to our
mentors and org admins that created 25 GSoC Org videos

helping interested participants understand more about the many 

Re: Season of KDE 2023 Ideas page skeleton is live

[Johnny Jazeix]

Hi,

a kind reminder. For now, there are 2 projects to improve the accessibility
of QML apps and websites.
Remember that the SoK is not only about code, but can also be about
documentation or other relevant stuff for KDE.

If there are no more ideas (GCompris and Krita won't be participating for
sure from feedback), I'm not sure it's worth doing a SoK for 2 projects but
we can still try to promote the projects to get new contributors to work on
them.

Cheers,

Johnny

Le sam. 12 nov. 2022 à 19:50, Johnny Jazeix  a écrit :

> Hi,
> The timeline for this year SoK is not yet decided but
> https://community.kde.org/SoK/Ideas/2023 is created for mentors to add
> their ideas.
>
> If you are adding an idea, please remember to put your own contact
> information in the description as the mentor. Do not add ideas with no
> mentor and contact info.
>
> Remember that SoK is more general than GSoC, so these ideas are not
> limited only to coding tasks and you can include projects related to
> documentation, artwork, translation, reports and other types of work as
> well as code.
>
> Cheers,
>
> Johnny
>
> ps: if anyone is willing to help for administer the event (preparing blog
> post, reminding people to do things...), please raise your hand, you are
> welcome!
>
>

Re: Season of KDE 2023 Ideas page skeleton is live

[Johnny Jazeix]

Hi,

a kind reminder. For now, there are 2 projects to improve the accessibility
of QML apps and websites.
Remember that the SoK is not only about code, but can also be about
documentation or other relevant stuff for KDE.

If there are no more ideas (GCompris and Krita won't be participating for
sure from feedback), I'm not sure it's worth doing a SoK for 2 projects but
we can still try to promote the projects to get new contributors to work on
them.

Cheers,

Johnny

Le sam. 12 nov. 2022 à 19:50, Johnny Jazeix  a écrit :

> Hi,
> The timeline for this year SoK is not yet decided but
> https://community.kde.org/SoK/Ideas/2023 is created for mentors to add
> their ideas.
>
> If you are adding an idea, please remember to put your own contact
> information in the description as the mentor. Do not add ideas with no
> mentor and contact info.
>
> Remember that SoK is more general than GSoC, so these ideas are not
> limited only to coding tasks and you can include projects related to
> documentation, artwork, translation, reports and other types of work as
> well as code.
>
> Cheers,
>
> Johnny
>
> ps: if anyone is willing to help for administer the event (preparing blog
> post, reminding people to do things...), please raise your hand, you are
> welcome!
>
>

Season of KDE 2023 Ideas page skeleton is live

[Johnny Jazeix]

Hi,
The timeline for this year SoK is not yet decided but
https://community.kde.org/SoK/Ideas/2023 is created for mentors to add
their ideas.

If you are adding an idea, please remember to put your own contact
information in the description as the mentor. Do not add ideas with no
mentor and contact info.

Remember that SoK is more general than GSoC, so these ideas are not limited
only to coding tasks and you can include projects related to documentation,
artwork, translation, reports and other types of work as well as code.

Cheers,

Johnny

ps: if anyone is willing to help for administer the event (preparing blog
post, reminding people to do things...), please raise your hand, you are
welcome!

Season of KDE 2023 Ideas page skeleton is live

[Johnny Jazeix]

Hi,
The timeline for this year SoK is not yet decided but
https://community.kde.org/SoK/Ideas/2023 is created for mentors to add
their ideas.

If you are adding an idea, please remember to put your own contact
information in the description as the mentor. Do not add ideas with no
mentor and contact info.

Remember that SoK is more general than GSoC, so these ideas are not limited
only to coding tasks and you can include projects related to documentation,
artwork, translation, reports and other types of work as well as code.

Cheers,

Johnny

ps: if anyone is willing to help for administer the event (preparing blog
post, reminding people to do things...), please raise your hand, you are
welcome!

Re: Copying po/docbook files to repositories nightly

[Johnny Jazeix]

Le dim. 2 oct. 2022 à 07:51, Albert Astals Cid  a écrit :

> El diumenge, 2 d’octubre de 2022, a les 7:37:26 (CEST), Albert Astals Cid
> va
> escriure:
> > El divendres, 2 de setembre de 2022, a les 23:24:21 (CEST), Albert Astals
> > Cid
> > va escriure:
> > > As you may know, translations for apps don't live in the same place as
> the
> > > code for the apps themselves.
> > >
> > > This greatly benefits translators but is not awesome for the release
> > > management side of things since it means that for each release we need
> to
> > > not forget to copy the appropriate files to the appropriate place,
> makes
> > > tagging somewhat harder, etc.
> > >
> > > For a while now we have been running an "experimental"
> copy-po-qm-docbook-
> > > back-to-repository in a number of "select" repositories and it seems to
> > > have worked quite well, you can seem one example in
> > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po
> > >
> > > The idea is to enable this for all repositories.
> >
> > This has now been enabled for master branch and according to scripty logs
> > all seems to have worked.
> >
> > Please inspect your repositories and make sure the po files are there
> where
> > they should and nothing broke.
>
> Nothing broke but at least it seems the po files did not get commited to
> these
> projects (maybe there are some more problematic repots, please check yours
> if
> it's not part of KDE Gear, KDE Framworks or Plasma, those are the ones i
> did
> check more thoroughly and fix if found something)
>
> digikam
> gcompris
> kaffeine
> kbibtex
> kphotoalbum
> kst-plot
> rkward
> skrooge
> trojita
> ubiquity-slideshow-neon
>
> Because it is ignoring the po folder at the .gitignore file level, please
> don't
> do that anymore.
>
> Cheers,
>   Albert
>
>
I've fixed it for GCompris and its website.

Thanks,

Johnny


> >
> > Also please make sure you adapt your releasing scripts if you release
> from
> > master.
> >
> > Cheers,
> >   Albert
> >
> > > This is a heads up, as a developer there's nothing you need to do, at
> most
> > > remove the po/ folder from .gitignore if for some reason it is there.
> > >
> > > If you're a packager you will need to make sure your scripts don't try
> to
> > > copy po/qm/docbook files anymore when doing a release once this is
> > > activated.
> > >
> > > My plan would be to enable this scripts over Akademy so we have the
> high
> > > bandwidth there to fix things if needed.
> > >
> > > Opinions? Comments?
> > >
> > > Cheers,
> > >
> > >   Albert
>
>
>
>
>

Re: Copying po/docbook files to repositories nightly

[Johnny Jazeix]

Le dim. 4 sept. 2022 à 11:14, Albert Astals Cid  a écrit :

> El dissabte, 3 de setembre de 2022, a les 10:44:01 (CEST), Johnny Jazeix
> va
> escriure:
> > Hi,
> >
> > this is great. For GCompris, we have some stuff to handle translation
> that
> > differs from the usual (for example, the po files are in
> > po/gcompris_.po, not po//gcompris_qt.po). I'll take a look to
> > harmonise it with the usual.
> > For the stable branch, we don't plan to do a release before December so
> it
> > would be better to not apply it at Akademy (except if the change on
> > GCompris side is easily backportable but I have to check).
>
> If you don't plan to do a release before December you have 3 months to
> make
> sure it works, i don't understand the problem.
>
> Albert
>
>
Priorities and time it requires to update the actual process. It's not just
changing the handling of the tree of files, it's also make sure we don't
ship translations with enough content and have it in a transparent way for
each platform.
For now, it's a script that fetch the po files and only take in account the
good ones, we make a release tgz and we use it on all platforms.
With this change, all the po will already be there (even the ones we don't
want to ship) so we need to ensure at build time that the languages we
don't want won't be in packages.

Regarding the actual stable branch, even if we don't plan to make releases,
it will still mean the new po files will be added in git so we need to
ensure it does not break the actual flow in this branch or ship unwanted
files.

So yes, the work to do is defined, the available time, less.

It will probably be done on time but the aim of this thread was to give
opinions (big +1 on the idea) and comments (there is work to do, it's worth
it but not free).

Cheers,

Johnny



> >
> > Cheers,
> >
> > Johnny
> >
> > Le sam. 3 sept. 2022 à 09:47, Albert Astals Cid  a écrit
> :
> > > El dissabte, 3 de setembre de 2022, a les 1:01:47 (CEST), Ömer Fadıl
> USTA
> > > va
> > >
> > > escriure:
> > > > Just wanted to learn one thing , isn't this will populate the logs
> with
> > > > lots of entries on git log history ?
> > > > I mean right now I am tracking git changes based on changes in
> history
> > >
> > > but
> > >
> > > > this will add a new entry
> > > > each night or I understand this wrong ?
> > >
> > > If you look a the example URL i posted you can see there's not a new
> entry
> > > each night.
> > >
> > > Cheers,
> > >
> > >   Albert
> > >
> > > > Also wouldn't it be possible to fetch related translation on the fly
> > > > from
> > > > the software side after releases ?
> > > > I mean translation of language X might be getting a little back lets
> say
> > > > 5.26 released but team X
> > > > might be late to complete their translation on time but user should
> have
> > > > chance to download it
> > > > after the release of it (without waiting for the next tagging ).
> > > > Wouldn't
> > > > it be possible to download and install the latest
> > > > language data in applications just like users do with themes?
> > > >
> > > > Thank you
> > > >
> > > > Ömer Fadıl Usta
> > > > PGP key : 0xfd11561976b1690b
> > > > about.me/omerusta
> > > >
> > > >
> > > > Albert Astals Cid , 3 Eyl 2022 Cmt, 00:25 tarihinde
> şunu
> > > >
> > > > yazdı:
> > > > > As you may know, translations for apps don't live in the same
> place as
> > >
> > > the
> > >
> > > > > code for the apps themselves.
> > > > >
> > > > > This greatly benefits translators but is not awesome for the
> release
> > > > > management
> > > > > side of things since it means that for each release we need to not
> > >
> > > forget
> > >
> > > > > to
> > > > > copy the appropriate files to the appropriate place, makes tagging
> > > > > somewhat
> > > > > harder, etc.
> > > > >
> > > > > For a while now we have been running an "experimental"
> > >
> > > copy-po-qm-docbook-
> > >
> > > > > back-to-repository in a number of "select" repositories and it
> seems
> > > > > to
> > > > > have
> > > > > worked quite well, you can seem one example in
> > > > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po
> > > > >
> > > > > The idea is to enable this for all repositories.
> > > > >
> > > > > This is a heads up, as a developer there's nothing you need to do,
> at
> > >
> > > most
> > >
> > > > > remove the po/ folder from .gitignore if for some reason it is
> there.
> > > > >
> > > > > If you're a packager you will need to make sure your scripts don't
> try
> > >
> > > to
> > >
> > > > > copy
> > > > > po/qm/docbook files anymore when doing a release once this is
> > >
> > > activated.
> > >
> > > > > My plan would be to enable this scripts over Akademy so we have the
> > >
> > > high
> > >
> > > > > bandwidth there to fix things if needed.
> > > > >
> > > > > Opinions? Comments?
> > > > >
> > > > > Cheers,
> > > > >
> > > > >   Albert
>
>
>
>
>

Re: Gitlab CI Dashboards and retirement of build.kde.org

[Johnny Jazeix]

Le sam. 3 sept. 2022 à 21:28, Ben Cooksley  a écrit :

> On Sat, Sep 3, 2022 at 9:29 PM Gleb Popov <6year...@gmail.com> wrote:
>
>> On Sat, Sep 3, 2022 at 7:46 AM Ben Cooksley  wrote:
>> >
>> > As previously indicated, I have now shutdown build.kde.org along with
>> the domain that supported it's version of the CI tooling.
>> > The repository containing that tooling has now also been archived, and
>> the former build.kde.org domain has been redirected to metrics.kde.org.
>> >
>> > The server which was acting as a builder for build.kde.org will be
>> rebuilt in the coming days and reallocated to support Gitlab CI workloads.
>> >
>> > Thanks,
>> > Ben
>>
>> What should be used instead of binary-factory? How do I transform this
>> link?
>>
>>
>> https://binary-factory.kde.org/view/Windows%2064-bit/job/Kate_Release_win64/1762/artifact/kate-22.08.0-1762-windows-msvc2019_64-cl.exe
>
>
> At this time the Binary Factory is not impacted by this.
>
> Regards,
> Ben
>

Hi,

I think the issue mentioned by Glen is that this link (and all other
artifacts from binary-factory) is redirected to
https://build-artifacts.kde.org/binary-factory/Kate_Release_win64/1762/kate-22.08.0-1762-windows-msvc2019_64-cl.exe
which does not exist.

Cheers,
Johnny

Re: Gitlab CI Dashboards and retirement of build.kde.org

[Johnny Jazeix]

Le sam. 3 sept. 2022 à 21:28, Ben Cooksley  a écrit :

> On Sat, Sep 3, 2022 at 9:29 PM Gleb Popov <6year...@gmail.com> wrote:
>
>> On Sat, Sep 3, 2022 at 7:46 AM Ben Cooksley  wrote:
>> >
>> > As previously indicated, I have now shutdown build.kde.org along with
>> the domain that supported it's version of the CI tooling.
>> > The repository containing that tooling has now also been archived, and
>> the former build.kde.org domain has been redirected to metrics.kde.org.
>> >
>> > The server which was acting as a builder for build.kde.org will be
>> rebuilt in the coming days and reallocated to support Gitlab CI workloads.
>> >
>> > Thanks,
>> > Ben
>>
>> What should be used instead of binary-factory? How do I transform this
>> link?
>>
>>
>> https://binary-factory.kde.org/view/Windows%2064-bit/job/Kate_Release_win64/1762/artifact/kate-22.08.0-1762-windows-msvc2019_64-cl.exe
>
>
> At this time the Binary Factory is not impacted by this.
>
> Regards,
> Ben
>

Hi,

I think the issue mentioned by Glen is that this link (and all other
artifacts from binary-factory) is redirected to
https://build-artifacts.kde.org/binary-factory/Kate_Release_win64/1762/kate-22.08.0-1762-windows-msvc2019_64-cl.exe
which does not exist.

Cheers,
Johnny

Re: Gitlab CI Dashboards and retirement of build.kde.org

[Johnny Jazeix]

Le sam. 3 sept. 2022 à 21:28, Ben Cooksley  a écrit :

> On Sat, Sep 3, 2022 at 9:29 PM Gleb Popov <6year...@gmail.com> wrote:
>
>> On Sat, Sep 3, 2022 at 7:46 AM Ben Cooksley  wrote:
>> >
>> > As previously indicated, I have now shutdown build.kde.org along with
>> the domain that supported it's version of the CI tooling.
>> > The repository containing that tooling has now also been archived, and
>> the former build.kde.org domain has been redirected to metrics.kde.org.
>> >
>> > The server which was acting as a builder for build.kde.org will be
>> rebuilt in the coming days and reallocated to support Gitlab CI workloads.
>> >
>> > Thanks,
>> > Ben
>>
>> What should be used instead of binary-factory? How do I transform this
>> link?
>>
>>
>> https://binary-factory.kde.org/view/Windows%2064-bit/job/Kate_Release_win64/1762/artifact/kate-22.08.0-1762-windows-msvc2019_64-cl.exe
>
>
> At this time the Binary Factory is not impacted by this.
>
> Regards,
> Ben
>

Hi,

I think the issue mentioned by Glen is that this link (and all other
artifacts from binary-factory) is redirected to
https://build-artifacts.kde.org/binary-factory/Kate_Release_win64/1762/kate-22.08.0-1762-windows-msvc2019_64-cl.exe
which does not exist.

Cheers,
Johnny

Re: Copying po/docbook files to repositories nightly

[Johnny Jazeix]

Hi,

this is great. For GCompris, we have some stuff to handle translation that
differs from the usual (for example, the po files are in
po/gcompris_.po, not po//gcompris_qt.po). I'll take a look to
harmonise it with the usual.
For the stable branch, we don't plan to do a release before December so it
would be better to not apply it at Akademy (except if the change on
GCompris side is easily backportable but I have to check).

Cheers,

Johnny

Le sam. 3 sept. 2022 à 09:47, Albert Astals Cid  a écrit :

> El dissabte, 3 de setembre de 2022, a les 1:01:47 (CEST), Ömer Fadıl USTA
> va
> escriure:
> > Just wanted to learn one thing , isn't this will populate the logs with
> > lots of entries on git log history ?
> > I mean right now I am tracking git changes based on changes in history
> but
> > this will add a new entry
> > each night or I understand this wrong ?
>
> If you look a the example URL i posted you can see there's not a new entry
> each night.
>
> Cheers,
>   Albert
>
> > Also wouldn't it be possible to fetch related translation on the fly from
> > the software side after releases ?
> > I mean translation of language X might be getting a little back lets say
> > 5.26 released but team X
> > might be late to complete their translation on time but user should have
> > chance to download it
> > after the release of it (without waiting for the next tagging ). Wouldn't
> > it be possible to download and install the latest
> > language data in applications just like users do with themes?
> >
> > Thank you
> >
> > Ömer Fadıl Usta
> > PGP key : 0xfd11561976b1690b
> > about.me/omerusta
> >
> >
> > Albert Astals Cid , 3 Eyl 2022 Cmt, 00:25 tarihinde şunu
> >
> > yazdı:
> > > As you may know, translations for apps don't live in the same place as
> the
> > > code for the apps themselves.
> > >
> > > This greatly benefits translators but is not awesome for the release
> > > management
> > > side of things since it means that for each release we need to not
> forget
> > > to
> > > copy the appropriate files to the appropriate place, makes tagging
> > > somewhat
> > > harder, etc.
> > >
> > > For a while now we have been running an "experimental"
> copy-po-qm-docbook-
> > > back-to-repository in a number of "select" repositories and it seems to
> > > have
> > > worked quite well, you can seem one example in
> > > https://invent.kde.org/plasma-mobile/alligator/-/commits/master/po
> > >
> > > The idea is to enable this for all repositories.
> > >
> > > This is a heads up, as a developer there's nothing you need to do, at
> most
> > > remove the po/ folder from .gitignore if for some reason it is there.
> > >
> > > If you're a packager you will need to make sure your scripts don't try
> to
> > > copy
> > > po/qm/docbook files anymore when doing a release once this is
> activated.
> > >
> > > My plan would be to enable this scripts over Akademy so we have the
> high
> > > bandwidth there to fix things if needed.
> > >
> > > Opinions? Comments?
> > >
> > > Cheers,
> > >
> > >   Albert
>
>
>
>
>

Re: [QML] Having different imports depending on Qt version

[Johnny Jazeix]

Le dim. 19 juin 2022 à 13:05, Albert Astals Cid  a écrit :

> El dissabte, 18 de juny de 2022, a les 14:24:21 (CEST), Johnny Jazeix va
> escriure:
> > Hi,
> >
> > for GCompris (compiled in Qt5 only), we have activities using the
> Calendar
> > qml object.
> >
> > Previously, we imported the one from QtQuick.Controls 1 but this module
> has
> > been deprecated and we switched to QtQuick.Controls 2. This component
> > hasn't been implemented in QtQuick.Controls 2 before Qt6.3 (via "import
> > QtQuick.Controls").
> >
> > This one is available in Qt Marketplace (
> > https://code.qt.io/cgit/qt-extensions/qtquickcalendar.git) and supports
> Qt5
> > and Qt 6.0-> 6.2 (via "import QtQuick.Calendar 1.0")  but requires
> > QtControls private headers to be installed and they are not present on
> some
> > distributions (Ubuntu < 21.04...), which we would like to still support
> for
> > the next version.
> >
> > There is the one in Qt.labs which is available in Qt5 but not Qt6 (via
> > "import Qt.labs.calendar 1.0").
> >
> > GCompris' code works fine with any of the import (
> >
> https://invent.kde.org/education/gcompris/-/blob/master/src/activities/calen
> > dar/Calendar.qml#L14) but I didn't find any "if(Qt_version < ...) use
> one,
> > else the other" except doing a Calendar.qml.cmake with a @GOOD_IMPORT@
> that
> > would be set by cmake and a configure_file.
> > Is there a better way?
> >
> > For now,  we only target Qt5, so we could use Qt.labs without having to
> > handle the other two but once we switch to Qt6, we will face the issue
> with
> > distributions using Qt6.2 so I'd rather prepare this transition sooner
> than
> > later.
>
> As you have found, tou need to have two different codebases for Qt5 and
> Qt6.
>
> QML doesn't have "ifdef", the only way I've been able to simulate
> something
> like in pure QML that is having a Loader loads "the old version" and then
> reacting to the Loader status changing to Loader.Error and trying to old
> "the
> new version".
>
> Another somewhat less ugly way way is simply having a C++ singleton or
> something that tells you the Qt version and then also using a Loader to do
> the
> same
>
> Loader {
> source: Singleton.isQt6 ? "Qt6Code.qml" : "Qt5Code.qml"
> }
>
>
Thank you for confirming there is no "clean" (as without duplicating the
code) way to do it.
I've still used the "configure_file" solution as it is the one that does
not duplicate files.

Cheers,
Johnny


> Cheers,
>   Albert
>
> >
> > Cheers,
> >
> > Johnny
>
>
>
>
>

[QML] Having different imports depending on Qt version

[Johnny Jazeix]

Hi,

for GCompris (compiled in Qt5 only), we have activities using the Calendar
qml object.

Previously, we imported the one from QtQuick.Controls 1 but this module has
been deprecated and we switched to QtQuick.Controls 2. This component
hasn't been implemented in QtQuick.Controls 2 before Qt6.3 (via "import
QtQuick.Controls").

This one is available in Qt Marketplace (
https://code.qt.io/cgit/qt-extensions/qtquickcalendar.git) and supports Qt5
and Qt 6.0-> 6.2 (via "import QtQuick.Calendar 1.0")  but requires
QtControls private headers to be installed and they are not present on some
distributions (Ubuntu < 21.04...), which we would like to still support for
the next version.

There is the one in Qt.labs which is available in Qt5 but not Qt6 (via
"import Qt.labs.calendar 1.0").

GCompris' code works fine with any of the import (
https://invent.kde.org/education/gcompris/-/blob/master/src/activities/calendar/Calendar.qml#L14)
but I didn't find any "if(Qt_version < ...) use one, else the other" except
doing a Calendar.qml.cmake with a @GOOD_IMPORT@ that would be set by cmake
and a configure_file.
Is there a better way?

For now,  we only target Qt5, so we could use Qt.labs without having to
handle the other two but once we switch to Qt6, we will face the issue with
distributions using Qt6.2 so I'd rather prepare this transition sooner than
later.

Cheers,

Johnny

Re: Regarding participation in GSoC

[Johnny Jazeix]

Hi Aditya,

please take a look at the KDE GSoC page (
https://community.kde.org/GSoC/2022/Ideas#GCompris) to contact the team and
know the next steps in order to start contributing. There is a mailing list
(gcompris-de...@kde.org) and a Matrix room (
https://webchat.kde.org/#/room/#gcompris:kde.org).

Cheers,

Johnny

Le mer. 23 mars 2022 à 07:50, Aditya Suthar  a
écrit :

> Hello, It's Aditya Suthar from India. I am a 1st year CSE student at GEC
> Bikaner(Rajsthan). I wish to contribute to GSoC through GCompris. I like
> the way it makes education very easy and interactive for children. The
> activities present in it will train their mind to think and explore.
>

Re: Contacting the mentors

[Johnny Jazeix]

Hi Nimish,

where did you find this project? I don't see any project in
https://community.kde.org/GSoC/2022/Ideas mentored by Simon.
In all cases, the best way is to contact the mailing list after you have
subscribed (and you can check the archives to be sure the mail was sent)
and/or contact the team via irc/matrix.

Cheers,

Johnny

Le sam. 12 mars 2022 à 07:27, Nimish Purohit  a
écrit :

> I am Nimish Purohit, a second year undergraduate and I am interested in
> Mr. Simon Redman's GSoC project. But I have been unable to contact him
> directly despite trying the given contract methods. Can someone help
> in this regard?
>

Re: Updates to sysadmin/repo-metadata - project topics

[Johnny Jazeix]

Thank you Nicolás!

Le lun. 21 févr. 2022 à 18:41, Nicolás Alvarez 
a écrit :

> It turns out the syncing of topics is giving this error, I guess it
> doesn't like "Qt" as a topic:
>
> 422 {"message": "Validation Failed", "errors": ["Topics must start
> with a lowercase letter or number, consist of 35 characters or less,
> and can include hyphens."], "documentation_url": "https://docs.git
> hub.com/rest/reference/repos#replace-all-repository-topics"}
>
> And since the hook fails after getting the error, it doesn't even push
> the commits...
>
> --
> Nicolás
>
> El lun, 21 feb 2022 a la(s) 09:02, Johnny Jazeix (jaz...@gmail.com)
> escribió:
> >
> > Hi,
> >
> > Isn't the synchro handled automagically? There has been a few commits in
> the last week pushed in invent.kde.org (
> https://invent.kde.org/education/gcompris/-/commits/master) but as you
> say they are not in the GitHub mirror.
> >
> > Cheers,
> >
> > Johnny
> >
> > Le lun. 21 févr. 2022 à 11:11, Ben Cooksley  a écrit
> :
> >>
> >> On Mon, Feb 21, 2022 at 5:41 AM Johnny Jazeix  wrote:
> >>>
> >>> Hi,
> >>
> >>
> >> Hi Johnny,
> >>
> >>>
> >>>
> >>> Thanks for the feature!
> >>>
> >>> I've added some for GCompris (
> https://invent.kde.org/sysadmin/repo-metadata/-/commit/43a83ede83402ca906a3ae85f84db1c4b27f3c2a)
> but I don't see them in https://github.com/KDE/gcompris. Is there
> something to trigger so they can appear?
> >>
> >>
> >> We only sync changes to GitHub when the repository is pushed to, and it
> looks like GCompris itself hasn't been pushed to since you made that change.
> >> Once you do that the changes will be synced.
> >>
> >>>
> >>>
> >>> Cheers,
> >>>
> >>> Johnny
> >>
> >>
> >> Cheers,
> >> Ben
> >>
> >>>
> >>>
> >>> Le dim. 13 févr. 2022 à 10:47, Alexander Semke 
> a écrit :
> >>>>
> >>>> On Montag, 7. Februar 2022 11:05:26 CET Ben Cooksley wrote:
> >>>> > Once specified in sysadmin/repo-metadata, this information will be
> >>>> > propagated to your GitHub project mirror to aid in the
> discoverability of
> >>>> > your project. See
> >>>> >
> https://invent.kde.org/sysadmin/repo-metadata/commit/f54a6b2837f3fdfd6237257
> >>>> > ee948449306b58567 and https://github.com/KDE/labplot for an
> example of this.
> >>>> Thanks, Ben!
> >>>>
> >>>> Cheers,
> >>>> Alexander
> >>>>
> >>>>
>

Re: Updates to sysadmin/repo-metadata - project topics

[Johnny Jazeix]

Hi,

Isn't the synchro handled automagically? There has been a few commits in
the last week pushed in invent.kde.org (
https://invent.kde.org/education/gcompris/-/commits/master) but as you say
they are not in the GitHub mirror.

Cheers,

Johnny

Le lun. 21 févr. 2022 à 11:11, Ben Cooksley  a écrit :

> On Mon, Feb 21, 2022 at 5:41 AM Johnny Jazeix  wrote:
>
>> Hi,
>>
>
> Hi Johnny,
>
>
>>
>> Thanks for the feature!
>>
>> I've added some for GCompris (
>> https://invent.kde.org/sysadmin/repo-metadata/-/commit/43a83ede83402ca906a3ae85f84db1c4b27f3c2a)
>> but I don't see them in https://github.com/KDE/gcompris. Is there
>> something to trigger so they can appear?
>>
>
> We only sync changes to GitHub when the repository is pushed to, and it
> looks like GCompris itself hasn't been pushed to since you made that change.
> Once you do that the changes will be synced.
>
>
>>
>> Cheers,
>>
>> Johnny
>>
>
> Cheers,
> Ben
>
>
>>
>> Le dim. 13 févr. 2022 à 10:47, Alexander Semke 
>> a écrit :
>>
>>> On Montag, 7. Februar 2022 11:05:26 CET Ben Cooksley wrote:
>>> > Once specified in sysadmin/repo-metadata, this information will be
>>> > propagated to your GitHub project mirror to aid in the discoverability
>>> of
>>> > your project. See
>>> >
>>> https://invent.kde.org/sysadmin/repo-metadata/commit/f54a6b2837f3fdfd6237257
>>> > ee948449306b58567 and https://github.com/KDE/labplot for an example
>>> of this.
>>> Thanks, Ben!
>>>
>>> Cheers,
>>> Alexander
>>>
>>>
>>>

Re: Updates to sysadmin/repo-metadata - project topics

[Johnny Jazeix]

Hi,

Thanks for the feature!

I've added some for GCompris (
https://invent.kde.org/sysadmin/repo-metadata/-/commit/43a83ede83402ca906a3ae85f84db1c4b27f3c2a)
but I don't see them in https://github.com/KDE/gcompris. Is there something
to trigger so they can appear?

Cheers,

Johnny

Le dim. 13 févr. 2022 à 10:47, Alexander Semke  a
écrit :

> On Montag, 7. Februar 2022 11:05:26 CET Ben Cooksley wrote:
> > Once specified in sysadmin/repo-metadata, this information will be
> > propagated to your GitHub project mirror to aid in the discoverability of
> > your project. See
> >
> https://invent.kde.org/sysadmin/repo-metadata/commit/f54a6b2837f3fdfd6237257
> > ee948449306b58567 and https://github.com/KDE/labplot for an example of
> this.
> Thanks, Ben!
>
> Cheers,
> Alexander
>
>
>

Re: Genderidentity

[Johnny Jazeix]

Le ven. 7 janv. 2022 à 23:11, Ian Wadham  a écrit :

> The original sentence:
> "Place %n boy(s) and %n girl(s) in the center. Then split %n pieces of
> candy equally between them.”
>
> could maybe be changed to:
> “Place some children in the center, %n from the left and %n from the right.
> Then split %n pieces of candy equally between them.”
>
> Perhaps that would solve two problems, Johnny Jazeix’s original  coding
> problem with the numbers and Sandro’s problem with the gendered words.
>
> FWIW, 75 years ago I disliked being called a child or worse still a kid.
> Schools
> I attended were single-sex and class-distinction was rife. So was bullying.
>
> Today’s schools have come a long way!
>
> Cheers, Ian W.
>
>
Hi,

this idea will cause issues on the ergonomy side. Where it would work fine
on computers, it will not work on phones where space is limited. For now,
on these devcies, we display the bar containing the children to drag on top
instead of left to have enough space on the center for the drops. We can't
add on in the bottom, it would not be practical.

Cheers,

Johnny

Re: Genderidentity

[Johnny Jazeix]

Hi,

As you said, this is off-topic regarding the initial issue (the problem
will still be present even if the proposed changes here are applied). I was
really reluctant to reply because it's a delicate subject, more
philosophical/political/social than related to GCompris and I don't really
want to take too much of my time on these kind of discussion. I'm not
saying it is not an important or valid concern, I'm saying that I would
prefer to use my time on other subjects. But, in the actual world, not
replying would probably be seen by some as I'm against it or I don't care
(and by an extrapolation, I would be against it) because I initiated the
thread (or even worse it could be said it's the position of GCompris
community). Also, this answer is a personal answer, anybody in the GCompris
community may or may not share it, it's not relevant here.

I just kept the kde-devel mailing list in the loop because this thread
originated here, let's not "spam" the other lists please.

The code is open, feel free to make a MR or open a bug/feature
request/discussion with the team to propose your ideas for the activity.
Just discussing here won't move things. Please note that it is not just
about changing this specific string. the whole activity would be impacted:
a lot of other strings/variables related, images, translation, voices...

" And than I read about this thread, that a program that is made for kids
is
teaching them the binary gender system and are telling me that is a good
thing
from a pedagogical point of view: Sorry NO! This is discriminating and
making
it less likely that we will overcome with the discrimination. "

It was never said by anyone that "binary gender system is teached by this
activity and it is good from a pedagogical point of view". It was said that
having 2 distinct sets was good for the pedagogical point of view.

Le jeu. 6 janv. 2022 à 20:01, Sandro Knauß  a écrit :

> Hey,
>
> > There is a time and place to teach kids about the complexity of gender
> > and I don't think an exercise about arithmetic/counting is the right
> > place.
>
> Fully ACK - I don't want to teach kids the complexity of gender. This
> exercise
> is about arithmetic/counting and should concentrate on that.
>
>
Then, when you use this activity with children, can you skip this part for
now and let the children focus on what the activity is about? And discuss
with them the complexity of gender later, when you feel it will be more
adequate for them?
The activity itself is just a tool designed to help teaching some math and
it is used by a person behind. It is up to the person to decide on how to
use the tool and what to focus on. Talking about the gender of the children
was never though or expected from the developers.

But I also don't need to teach them to seperate people by gender indirectly!
>
> Why not use cats and dogs or plants and animals as distinct sets? Than we
> are
> not hurting anyone.
>
>
I'm sure whatever is used, there will be someone who can be hurt and can
complain (rightfully or not). We are close to 8 billions of people in the
world and there is not one subject that we can all agree on. Why cats and
dogs and not rabbits and horses? Maybe this is not an important cause to
you because they are "generic" animals but for someone else it could be (or
some children using the software may have ailurophobia or cynophobia).
Note the activity for now is to share pieces of candy (let's not open a new
thread about the danger of sugar please). If we put animals instead of
people, indirectly children using the software could think it is a good
idea to give candies to their animals (which is not).
Only colors should be avoided because some children have poor or deficient
color vision.
Clothes: which kind? Some people may get offended because the size of the
T-shirt is "standard", not small or extra.

These examples can be seen as exagerations but there is nothing that can
guarantee nobody will get offended by any of these ideas (maybe not now but
what in 5/10/20 years?). And at that point, what do we do? Do we change
again?
On my side, I don't see any advantages on the pedagogic side to change the
activity to use something else that so I won't personally put efforts to
directly work on it (but if there is a MR, I will review it as any other
one), I have things I consider more important to work on GCompris.

The application is to be played by children, let's not extrapolate
everything and let's not add more activism than necessary in a software
designed for children.

Johnny

ps : please, don't assume by this answer that I am for or against the third
gender and not telling explicitely what is my opinion about it makes me by
default against it. I think it is just not the place in GCompris.

Re: Translation of plural string in English with spaces

[Johnny Jazeix]

Hi,
yes, the aim is to have 2 distinct sets for the pedagogical point of view,
it's a bit more complicated.

Johnny

Le jeu. 6 janv. 2022 à 12:37, Luciano Montanaro  a
écrit :

> It looks like the goal is to have two distinct sets, so that would not
> work.
>
> On Thu, Jan 6, 2022 at 10:55 AM Josep M. Ferrer 
> wrote:
> >
> > El 5/1/22 a les 21:07, Johnny Jazeix ha escrit:
> > > Hi,
> > >
> > > for GCompris we have one complicated sentence to translate:
> > > "Place %n boy(s) and %n girl(s) in the center. Then split %n pieces of
> > > candy equally between them." (context in this image:
> > > https://gcompris.net/screenshots_qt/middle/share.png)
> > >
> > > There are mixed plurals and to have the plural correctly translated we
> > > use:
> > > //~ singular Place %n boy
> > > //~ plural Place %n boys
> > > text = qsTr("Place %n boy(s) ", "First part of Place %n boy(s)
> > > and %n girl(s) in the center. Then split %n pieces of candy equally
> > > between them.", boys);
> > >
> > > //~ singular and %n girl in the center.
> > > //~ plural and %n girls in the center.
> > > text += qsTr("and %n girl(s) in the center. ", "Second part of
> > > Place %n boy(s) and %n girl(s) in the center. Then split %n pieces of
> > > candy equally between them.", girls);
> > >
> > > //~ singular Then split %n candy equally between them.
> > > //~ plural Then split %n candies equally between them.
> > > text += qsTr("Then split %n pieces of candy equally between
> > > them.", "Third part of Place %n boy(s) and %n girl(s) in the center.
> > > Then split %n pieces of candy equally between them.", candies);
> > >
> > > For American English, it takes the string from the " //~
> > > singular/plural " lines.
> > > The issue we have is that we don't manage to have the extra space in
> > > the English translation at the end of "boy(s) " (same if we put the
> > > space at the beginning of the other part to translate (" and %n
> > > girl(s))").
> > >
> > > If we add double quotes, they are part of the translation. And if we
> > > have an extra space at the end, it is removed.
> > >
> > > Is there a way to handle it properly in the code or even reformulate
> > > the sentence to make it work more easily while keeping the meaning?
> > >
> > > I'm cc-ing multiple list because, in the ideal, we'd like to fix the
> > > code without impacting the string for the next release but we can have
> > > a better string for after.
> > >
> > > Cheers,
> > >
> > > Johnny
> >
> > Hi,
> >
> > Instead "boys" and "girls", can we use a more neutral gender like
> > "kids"? And then this problem is gone :)
> >
> > Best regards,
> >
> > Josep M. Ferrer
> >
>
>
> --
> Luciano Montanaro
>
> Anyone who is capable of getting themselves made President should on
> no account be allowed to do the job. -- Douglas Adams
>

Translation of plural string in English with spaces

[Johnny Jazeix]

Hi,

for GCompris we have one complicated sentence to translate:
"Place %n boy(s) and %n girl(s) in the center. Then split %n pieces of
candy equally between them." (context in this image:
https://gcompris.net/screenshots_qt/middle/share.png)

There are mixed plurals and to have the plural correctly translated we use:
//~ singular Place %n boy
//~ plural Place %n boys
text = qsTr("Place %n boy(s) ", "First part of Place %n boy(s) and
%n girl(s) in the center. Then split %n pieces of candy equally between
them.", boys);

//~ singular and %n girl in the center.
//~ plural and %n girls in the center.
text += qsTr("and %n girl(s) in the center. ", "Second part of
Place %n boy(s) and %n girl(s) in the center. Then split %n pieces of candy
equally between them.", girls);

//~ singular Then split %n candy equally between them.
//~ plural Then split %n candies equally between them.
text += qsTr("Then split %n pieces of candy equally between them.",
"Third part of Place %n boy(s) and %n girl(s) in the center. Then split %n
pieces of candy equally between them.", candies);

For American English, it takes the string from the " //~ singular/plural "
lines.
The issue we have is that we don't manage to have the extra space in the
English translation at the end of "boy(s) " (same if we put the space at
the beginning of the other part to translate (" and %n girl(s))").

If we add double quotes, they are part of the translation. And if we have
an extra space at the end, it is removed.

Is there a way to handle it properly in the code or even reformulate the
sentence to make it work more easily while keeping the meaning?

I'm cc-ing multiple list because, in the ideal, we'd like to fix the code
without impacting the string for the next release but we can have a better
string for after.

Cheers,

Johnny

Re: Season of KDE 2022 Ideas page skeleton is live

[Johnny Jazeix]

Hi,
little mistake in my previous mail: it is up to the student to create the
project on the season.kde.org website after contacting their potential
mentors and discussing with them. Generally we also expect from the student
to write a bigger text than the one in the idea page.

Cheers,

Adam & Johnny


Le mer. 29 déc. 2021 à 15:40, Johnny Jazeix  a écrit :

> Hi,
> a kind reminder. We have updated the timeline on https://season.kde.org/.
> We want to start this season mid-January.
> For people willing to mentor, please don't forget to subscribe to the
> mentors list (Kde Soc Mentor ) and do a request
> to be a mentor too in the website if it is not yet the case.
>
> We will start copying the current ideas to the season.kde.org website
> during the next days.
>
> For students, ping the different teams/mentors if you want to participate
> to the SoK to know if they plan to participate, propose subjects if you
> have ideas.
>
> Cheers,
>
> Adam & Johnny
>
> Le mar. 14 déc. 2021 à 16:30, Johnny Jazeix  a écrit :
>
>> Hi,
>> We have not yet updated the main page at https://community.kde.org/SoK/
>> and https://season.kde.org/ with this year timeline.
>> However, https://community.kde.org/SoK/Ideas/2022 is live, as a skeleton.
>> We copied the /2021 page and removed all the ideas. If you are adding an
>> idea, please remember to put your own contact information in the
>> description as the mentor. Do not add Ideas with no mentor and contact
>> info.
>>
>> Remember that SoK is more general than GSoC, so these ideas are
>> not limited only to coding tasks and you can include projects related to
>> documentation, artwork, translation, reports and other types of work as
>> well as code.
>>
>> Cheers,
>>
>> Adam & Johnny
>>
>

Re: Season of KDE 2022 Ideas page skeleton is live

[Johnny Jazeix]

Hi,
little mistake in my previous mail: it is up to the student to create the
project on the season.kde.org website after contacting their potential
mentors and discussing with them. Generally we also expect from the student
to write a bigger text than the one in the idea page.

Cheers,

Adam & Johnny


Le mer. 29 déc. 2021 à 15:40, Johnny Jazeix  a écrit :

> Hi,
> a kind reminder. We have updated the timeline on https://season.kde.org/.
> We want to start this season mid-January.
> For people willing to mentor, please don't forget to subscribe to the
> mentors list (Kde Soc Mentor ) and do a request
> to be a mentor too in the website if it is not yet the case.
>
> We will start copying the current ideas to the season.kde.org website
> during the next days.
>
> For students, ping the different teams/mentors if you want to participate
> to the SoK to know if they plan to participate, propose subjects if you
> have ideas.
>
> Cheers,
>
> Adam & Johnny
>
> Le mar. 14 déc. 2021 à 16:30, Johnny Jazeix  a écrit :
>
>> Hi,
>> We have not yet updated the main page at https://community.kde.org/SoK/
>> and https://season.kde.org/ with this year timeline.
>> However, https://community.kde.org/SoK/Ideas/2022 is live, as a skeleton.
>> We copied the /2021 page and removed all the ideas. If you are adding an
>> idea, please remember to put your own contact information in the
>> description as the mentor. Do not add Ideas with no mentor and contact
>> info.
>>
>> Remember that SoK is more general than GSoC, so these ideas are
>> not limited only to coding tasks and you can include projects related to
>> documentation, artwork, translation, reports and other types of work as
>> well as code.
>>
>> Cheers,
>>
>> Adam & Johnny
>>
>

Re: Season of KDE 2022 Ideas page skeleton is live

[Johnny Jazeix]

Hi,
a kind reminder. We have updated the timeline on https://season.kde.org/.
We want to start this season mid-January.
For people willing to mentor, please don't forget to subscribe to the
mentors list (Kde Soc Mentor ) and do a request to
be a mentor too in the website if it is not yet the case.

We will start copying the current ideas to the season.kde.org website
during the next days.

For students, ping the different teams/mentors if you want to participate
to the SoK to know if they plan to participate, propose subjects if you
have ideas.

Cheers,

Adam & Johnny

Le mar. 14 déc. 2021 à 16:30, Johnny Jazeix  a écrit :

> Hi,
> We have not yet updated the main page at https://community.kde.org/SoK/
> and https://season.kde.org/ with this year timeline.
> However, https://community.kde.org/SoK/Ideas/2022 is live, as a skeleton.
> We copied the /2021 page and removed all the ideas. If you are adding an
> idea, please remember to put your own contact information in the
> description as the mentor. Do not add Ideas with no mentor and contact
> info.
>
> Remember that SoK is more general than GSoC, so these ideas are
> not limited only to coding tasks and you can include projects related to
> documentation, artwork, translation, reports and other types of work as
> well as code.
>
> Cheers,
>
> Adam & Johnny
>

Re: Season of KDE 2022 Ideas page skeleton is live

[Johnny Jazeix]

Hi,
a kind reminder. We have updated the timeline on https://season.kde.org/.
We want to start this season mid-January.
For people willing to mentor, please don't forget to subscribe to the
mentors list (Kde Soc Mentor ) and do a request to
be a mentor too in the website if it is not yet the case.

We will start copying the current ideas to the season.kde.org website
during the next days.

For students, ping the different teams/mentors if you want to participate
to the SoK to know if they plan to participate, propose subjects if you
have ideas.

Cheers,

Adam & Johnny

Le mar. 14 déc. 2021 à 16:30, Johnny Jazeix  a écrit :

> Hi,
> We have not yet updated the main page at https://community.kde.org/SoK/
> and https://season.kde.org/ with this year timeline.
> However, https://community.kde.org/SoK/Ideas/2022 is live, as a skeleton.
> We copied the /2021 page and removed all the ideas. If you are adding an
> idea, please remember to put your own contact information in the
> description as the mentor. Do not add Ideas with no mentor and contact
> info.
>
> Remember that SoK is more general than GSoC, so these ideas are
> not limited only to coding tasks and you can include projects related to
> documentation, artwork, translation, reports and other types of work as
> well as code.
>
> Cheers,
>
> Adam & Johnny
>

Season of KDE 2022 Ideas page skeleton is live

[Johnny Jazeix]

Hi,
We have not yet updated the main page at https://community.kde.org/SoK/ and
https://season.kde.org/ with this year timeline.
However, https://community.kde.org/SoK/Ideas/2022 is live, as a skeleton.
We copied the /2021 page and removed all the ideas. If you are adding an
idea, please remember to put your own contact information in the
description as the mentor. Do not add Ideas with no mentor and contact
info.

Remember that SoK is more general than GSoC, so these ideas are
not limited only to coding tasks and you can include projects related to
documentation, artwork, translation, reports and other types of work as
well as code.

Cheers,

Adam & Johnny

Season of KDE 2022 Ideas page skeleton is live

[Johnny Jazeix]

Hi,
We have not yet updated the main page at https://community.kde.org/SoK/ and
https://season.kde.org/ with this year timeline.
However, https://community.kde.org/SoK/Ideas/2022 is live, as a skeleton.
We copied the /2021 page and removed all the ideas. If you are adding an
idea, please remember to put your own contact information in the
description as the mentor. Do not add Ideas with no mentor and contact
info.

Remember that SoK is more general than GSoC, so these ideas are
not limited only to coding tasks and you can include projects related to
documentation, artwork, translation, reports and other types of work as
well as code.

Cheers,

Adam & Johnny

Re: Rollout of Gitlab CI

[Johnny Jazeix]

Le mer. 29 sept. 2021 à 19:37, Ben Cooksley  a écrit :

> On Thu, Sep 30, 2021 at 3:41 AM Johnny Jazeix  wrote:
>
>>
>>
>> Le mer. 29 sept. 2021 à 11:27, Ben Cooksley  a écrit :
>>
>>> Hi all,
>>>
>>> As those of you who watch and work on Frameworks repositories will be
>>> aware, we've just rolled out the first set of native Gitlab CI builds.
>>>
>>> These builds are at this time Linux only, but do include support for
>>> both regular branch builds as well as for Merge Requests. It is anticipated
>>> that Windows, FreeBSD and Android builds will follow in the near future -
>>> there are a few extra things we need to get completed first before they can
>>> be rolled out. As part of carrying out the build the scripts will also
>>> gather Code Coverage and Code Quality information using gcovr and cppcheck
>>> respectively, and this will be made available to you within the Gitlab
>>> interface.
>>>
>>> With regards to availability to projects outside Frameworks, projects
>>> that depend only on Frameworks (and no other KDE project) may enable CI for
>>> their project by adding the necessary .kde-ci.yml and .gitlab-ci.yml files
>>> to their repositories. I anticipate that once the necessary changes have
>>> been made to the "seed" jobs used to provision the initial artifacts it
>>> should be possible for all projects to rollout support (although i'd like
>>> to add ccache support to the system to ensure larger project builds
>>> complete promptly first).
>>>
>>> If anyone would like to help out with getting the seed jobs ready please
>>> let me know as this is definitely something that the community can assist
>>> with (and will also help with easing the rollout of Windows, FreeBSD and
>>> Android builds).
>>>
>>> For those projects that do go ahead with enabling Gitlab CI support
>>> please ensure you add the necessary .kde-ci.yml file beforehand, specifying
>>> in it the necessary Dependencies, as well as the necessary Options your
>>> project needs to customise for their build. A list of all the possible
>>> values in a .kde-ci.yml file can be found at
>>> https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/config-template.yml#L10
>>>
>>> For those projects that are not yet able to enable the system, it is
>>> strongly encouraged that you go ahead and get the .kde-ci.yml files ready
>>> in your repository now - especially if other projects depend on your
>>> project. This will allow the rollout of the CI system to those projects to
>>> proceed much more smoothly (otherwise we will need to get them added to
>>> those projects which have other projects depending on them).
>>>
>>> Please note that this new infrastructure replaces all existing Gitlab CI
>>> jobs we provided in the initial testing phase, and those should be removed
>>> (much like how I did for Frameworks) when switching to the new setup.
>>>
>>> Thanks,
>>> Ben
>>>
>>
>> Hi,
>>
>> is there a template for the .gitlab-ci.yml or should we use the same as
>> https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/63bec5521d245e3a1ea50109b86a2b716966938e
>> for example?
>>
>
> You can use the same as that file.
>
> We're not providing a .gitlab-ci.yml template as there will be Windows,
> FreeBSD and Android builds as well (and potentially in the future macOS as
> well) which are options that won't necessarily apply to all projects.
>
>
>> Cheers,
>>
>> Johnny
>>
>
> Cheers,
> Ben
>

Ok, super. It works fine for GCompris:
https://invent.kde.org/education/gcompris/-/tree/master

Thanks for providing this!

Johnny

Re: Rollout of Gitlab CI

[Johnny Jazeix]

Le mer. 29 sept. 2021 à 19:37, Ben Cooksley  a écrit :

> On Thu, Sep 30, 2021 at 3:41 AM Johnny Jazeix  wrote:
>
>>
>>
>> Le mer. 29 sept. 2021 à 11:27, Ben Cooksley  a écrit :
>>
>>> Hi all,
>>>
>>> As those of you who watch and work on Frameworks repositories will be
>>> aware, we've just rolled out the first set of native Gitlab CI builds.
>>>
>>> These builds are at this time Linux only, but do include support for
>>> both regular branch builds as well as for Merge Requests. It is anticipated
>>> that Windows, FreeBSD and Android builds will follow in the near future -
>>> there are a few extra things we need to get completed first before they can
>>> be rolled out. As part of carrying out the build the scripts will also
>>> gather Code Coverage and Code Quality information using gcovr and cppcheck
>>> respectively, and this will be made available to you within the Gitlab
>>> interface.
>>>
>>> With regards to availability to projects outside Frameworks, projects
>>> that depend only on Frameworks (and no other KDE project) may enable CI for
>>> their project by adding the necessary .kde-ci.yml and .gitlab-ci.yml files
>>> to their repositories. I anticipate that once the necessary changes have
>>> been made to the "seed" jobs used to provision the initial artifacts it
>>> should be possible for all projects to rollout support (although i'd like
>>> to add ccache support to the system to ensure larger project builds
>>> complete promptly first).
>>>
>>> If anyone would like to help out with getting the seed jobs ready please
>>> let me know as this is definitely something that the community can assist
>>> with (and will also help with easing the rollout of Windows, FreeBSD and
>>> Android builds).
>>>
>>> For those projects that do go ahead with enabling Gitlab CI support
>>> please ensure you add the necessary .kde-ci.yml file beforehand, specifying
>>> in it the necessary Dependencies, as well as the necessary Options your
>>> project needs to customise for their build. A list of all the possible
>>> values in a .kde-ci.yml file can be found at
>>> https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/config-template.yml#L10
>>>
>>> For those projects that are not yet able to enable the system, it is
>>> strongly encouraged that you go ahead and get the .kde-ci.yml files ready
>>> in your repository now - especially if other projects depend on your
>>> project. This will allow the rollout of the CI system to those projects to
>>> proceed much more smoothly (otherwise we will need to get them added to
>>> those projects which have other projects depending on them).
>>>
>>> Please note that this new infrastructure replaces all existing Gitlab CI
>>> jobs we provided in the initial testing phase, and those should be removed
>>> (much like how I did for Frameworks) when switching to the new setup.
>>>
>>> Thanks,
>>> Ben
>>>
>>
>> Hi,
>>
>> is there a template for the .gitlab-ci.yml or should we use the same as
>> https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/63bec5521d245e3a1ea50109b86a2b716966938e
>> for example?
>>
>
> You can use the same as that file.
>
> We're not providing a .gitlab-ci.yml template as there will be Windows,
> FreeBSD and Android builds as well (and potentially in the future macOS as
> well) which are options that won't necessarily apply to all projects.
>
>
>> Cheers,
>>
>> Johnny
>>
>
> Cheers,
> Ben
>

Ok, super. It works fine for GCompris:
https://invent.kde.org/education/gcompris/-/tree/master

Thanks for providing this!

Johnny

Re: Rollout of Gitlab CI

[Johnny Jazeix]

Le mer. 29 sept. 2021 à 11:27, Ben Cooksley  a écrit :

> Hi all,
>
> As those of you who watch and work on Frameworks repositories will be
> aware, we've just rolled out the first set of native Gitlab CI builds.
>
> These builds are at this time Linux only, but do include support for both
> regular branch builds as well as for Merge Requests. It is anticipated that
> Windows, FreeBSD and Android builds will follow in the near future - there
> are a few extra things we need to get completed first before they can be
> rolled out. As part of carrying out the build the scripts will also gather
> Code Coverage and Code Quality information using gcovr and cppcheck
> respectively, and this will be made available to you within the Gitlab
> interface.
>
> With regards to availability to projects outside Frameworks, projects that
> depend only on Frameworks (and no other KDE project) may enable CI for
> their project by adding the necessary .kde-ci.yml and .gitlab-ci.yml files
> to their repositories. I anticipate that once the necessary changes have
> been made to the "seed" jobs used to provision the initial artifacts it
> should be possible for all projects to rollout support (although i'd like
> to add ccache support to the system to ensure larger project builds
> complete promptly first).
>
> If anyone would like to help out with getting the seed jobs ready please
> let me know as this is definitely something that the community can assist
> with (and will also help with easing the rollout of Windows, FreeBSD and
> Android builds).
>
> For those projects that do go ahead with enabling Gitlab CI support please
> ensure you add the necessary .kde-ci.yml file beforehand, specifying in it
> the necessary Dependencies, as well as the necessary Options your project
> needs to customise for their build. A list of all the possible values in a
> .kde-ci.yml file can be found at
> https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/config-template.yml#L10
>
> For those projects that are not yet able to enable the system, it is
> strongly encouraged that you go ahead and get the .kde-ci.yml files ready
> in your repository now - especially if other projects depend on your
> project. This will allow the rollout of the CI system to those projects to
> proceed much more smoothly (otherwise we will need to get them added to
> those projects which have other projects depending on them).
>
> Please note that this new infrastructure replaces all existing Gitlab CI
> jobs we provided in the initial testing phase, and those should be removed
> (much like how I did for Frameworks) when switching to the new setup.
>
> Thanks,
> Ben
>

Hi,

is there a template for the .gitlab-ci.yml or should we use the same as
https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/63bec5521d245e3a1ea50109b86a2b716966938e
for example?

Cheers,

Johnny

Re: Gitlab CI - Inbound

[Johnny Jazeix]

Hi Ben,
not sure on which priority it is regarding the KDE Frameworks but I've
added one on GCompris (
https://invent.kde.org/education/gcompris/-/commit/67c9839d7970b360b5d6b0ec928b492f9003d07d)
if it can help on more tests.

Cheers,

Johnny

Le dim. 5 sept. 2021 à 12:11, Ben Cooksley  a écrit :

> On Sun, Sep 5, 2021 at 6:13 PM Ben Cooksley  wrote:
>
>> Hi all,
>>
>
> Hi all,
>
>
>> This morning after much work i'm happy to announce that the new
>> generation CI scripts intended for use with Gitlab CI successfully
>> completed their first build (of ECM, and then subsequently of KCoreAddons).
>>
>> This begins our first steps towards transferring CI over from Jenkins to
>> Gitlab.
>>
>> These scripts are 'Gitlab native' and are designed to work in an
>> environment where they will be running on merge requests, tags as well as
>> all branches of our repositories - something the existing scripts were
>> completely incompatible with. While there are still some infrastructural
>> elements to put in place (such as 'seed jobs' to mass rebuild all projects
>> after substantial changes and 'cleanup jobs' to remove old builds from the
>> Package Registry) the core elements needed for initial testing of these
>> scripts are now ready.
>>
>
> As an update, an initial version of the seed job tooling is now ready,
> however testing that tooling requires that dependency information be
> available.
> This requires that the .kde-ci.yml files be populated in repositories.
>
> It would be appreciated if people could please work on getting these files
> populated in Frameworks (as everyone needs those) as well as in their own
> repositories as they are required before we can proceed much further.
>
>
>> For those curious, the results of those initials runs can be found at
>> https://invent.kde.org/groups/teams/ci-artifacts/-/packages
>>
>> Due to the challenges associated with having to handle all of the
>> different forms of build and the versioning of this information, these
>> scripts also represent a radical change in how CI builds will be conducted
>> - with a large part of the configuration of the jobs themselves, including
>> information on project dependencies now shifting to files located within
>> the repository themselves. Those who monitor commits to Frameworks
>> repositories will have noticed the appearance of these '.kde-ci.yml' files
>> in some repositories.
>>
>> To assist in the future rollout of the CI system it would be appreciated
>> if projects could please begin setting up these files within their
>> respective repositories.
>> You can find a template detailing the available options at
>> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml
>>
>> Where possible please avoid overriding the system defaults except where
>> needed by your project (ie. don't just copy the template in full)
>> The defaults mirror the template and can be found at
>> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml
>>
>> In terms of the format of the 'Dependencies' section, please bear in mind
>> the following:
>> - For the 'on' section, the special value '@all' can be used to mean "All
>> platforms" to avoid needing to update the file in the event additional
>> platforms are added in the future
>> - For the 'require' section:
>>   1) Please only include the projects you *explicitly* depend on.
>> Dependencies of your dependencies will be included automatically
>>   2) When specifying a project, you must use the repository path on
>> Gitlab. Legacy project paths (such as kde/workspace/plasma-desktop) are no
>> longer in use and will not work.
>>   3) There are three special values for the branch name - '@same',
>> '@latest' and '@stable' which can be used to refer to the branch/tag of a
>> dependency.
>>   '@same' means the branch name should be the same as that of the
>> project being built and should be used when declaring dependencies among
>> projects in a release group.
>>   '@latest' and '@stable' refer to the corresponding branches defined
>> in the branch-rules.yml file, which can be found in sysadmin/repo-metadata
>>
>> As a general rule, unless you require the absolute latest version of
>> another project in another release unit, it is recommended that you use
>> @stable.
>> Please avoid using explicit branch names unless absolutely necessary.
>>
>> At this time it is expected that the first set of Gitlab CI builds using
>> the new scripts may be conducted for Frameworks within the next week or so,
>> assuming the build of the seed jobs goes according to plan.
>>
>> Once the scripts have been proven successfully for Frameworks, we will
>> look at extending them to projects that depend only on Frameworks and
>> repositories within their release unit and finally will extend them to
>> projects with more complex dependency requirements. It is expected that the
>> switch will be flipped on the Frameworks builds sometime in the 

Re: Gitlab CI - Inbound

[Johnny Jazeix]

Hi Ben,
not sure on which priority it is regarding the KDE Frameworks but I've
added one on GCompris (
https://invent.kde.org/education/gcompris/-/commit/67c9839d7970b360b5d6b0ec928b492f9003d07d)
if it can help on more tests.

Cheers,

Johnny

Le dim. 5 sept. 2021 à 12:11, Ben Cooksley  a écrit :

> On Sun, Sep 5, 2021 at 6:13 PM Ben Cooksley  wrote:
>
>> Hi all,
>>
>
> Hi all,
>
>
>> This morning after much work i'm happy to announce that the new
>> generation CI scripts intended for use with Gitlab CI successfully
>> completed their first build (of ECM, and then subsequently of KCoreAddons).
>>
>> This begins our first steps towards transferring CI over from Jenkins to
>> Gitlab.
>>
>> These scripts are 'Gitlab native' and are designed to work in an
>> environment where they will be running on merge requests, tags as well as
>> all branches of our repositories - something the existing scripts were
>> completely incompatible with. While there are still some infrastructural
>> elements to put in place (such as 'seed jobs' to mass rebuild all projects
>> after substantial changes and 'cleanup jobs' to remove old builds from the
>> Package Registry) the core elements needed for initial testing of these
>> scripts are now ready.
>>
>
> As an update, an initial version of the seed job tooling is now ready,
> however testing that tooling requires that dependency information be
> available.
> This requires that the .kde-ci.yml files be populated in repositories.
>
> It would be appreciated if people could please work on getting these files
> populated in Frameworks (as everyone needs those) as well as in their own
> repositories as they are required before we can proceed much further.
>
>
>> For those curious, the results of those initials runs can be found at
>> https://invent.kde.org/groups/teams/ci-artifacts/-/packages
>>
>> Due to the challenges associated with having to handle all of the
>> different forms of build and the versioning of this information, these
>> scripts also represent a radical change in how CI builds will be conducted
>> - with a large part of the configuration of the jobs themselves, including
>> information on project dependencies now shifting to files located within
>> the repository themselves. Those who monitor commits to Frameworks
>> repositories will have noticed the appearance of these '.kde-ci.yml' files
>> in some repositories.
>>
>> To assist in the future rollout of the CI system it would be appreciated
>> if projects could please begin setting up these files within their
>> respective repositories.
>> You can find a template detailing the available options at
>> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml
>>
>> Where possible please avoid overriding the system defaults except where
>> needed by your project (ie. don't just copy the template in full)
>> The defaults mirror the template and can be found at
>> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml
>>
>> In terms of the format of the 'Dependencies' section, please bear in mind
>> the following:
>> - For the 'on' section, the special value '@all' can be used to mean "All
>> platforms" to avoid needing to update the file in the event additional
>> platforms are added in the future
>> - For the 'require' section:
>>   1) Please only include the projects you *explicitly* depend on.
>> Dependencies of your dependencies will be included automatically
>>   2) When specifying a project, you must use the repository path on
>> Gitlab. Legacy project paths (such as kde/workspace/plasma-desktop) are no
>> longer in use and will not work.
>>   3) There are three special values for the branch name - '@same',
>> '@latest' and '@stable' which can be used to refer to the branch/tag of a
>> dependency.
>>   '@same' means the branch name should be the same as that of the
>> project being built and should be used when declaring dependencies among
>> projects in a release group.
>>   '@latest' and '@stable' refer to the corresponding branches defined
>> in the branch-rules.yml file, which can be found in sysadmin/repo-metadata
>>
>> As a general rule, unless you require the absolute latest version of
>> another project in another release unit, it is recommended that you use
>> @stable.
>> Please avoid using explicit branch names unless absolutely necessary.
>>
>> At this time it is expected that the first set of Gitlab CI builds using
>> the new scripts may be conducted for Frameworks within the next week or so,
>> assuming the build of the seed jobs goes according to plan.
>>
>> Once the scripts have been proven successfully for Frameworks, we will
>> look at extending them to projects that depend only on Frameworks and
>> repositories within their release unit and finally will extend them to
>> projects with more complex dependency requirements. It is expected that the
>> switch will be flipped on the Frameworks builds sometime in the 

Re: Gitlab CI - Inbound

[Johnny Jazeix]

Hi Ben,
not sure on which priority it is regarding the KDE Frameworks but I've
added one on GCompris (
https://invent.kde.org/education/gcompris/-/commit/67c9839d7970b360b5d6b0ec928b492f9003d07d)
if it can help on more tests.

Cheers,

Johnny

Le dim. 5 sept. 2021 à 12:11, Ben Cooksley  a écrit :

> On Sun, Sep 5, 2021 at 6:13 PM Ben Cooksley  wrote:
>
>> Hi all,
>>
>
> Hi all,
>
>
>> This morning after much work i'm happy to announce that the new
>> generation CI scripts intended for use with Gitlab CI successfully
>> completed their first build (of ECM, and then subsequently of KCoreAddons).
>>
>> This begins our first steps towards transferring CI over from Jenkins to
>> Gitlab.
>>
>> These scripts are 'Gitlab native' and are designed to work in an
>> environment where they will be running on merge requests, tags as well as
>> all branches of our repositories - something the existing scripts were
>> completely incompatible with. While there are still some infrastructural
>> elements to put in place (such as 'seed jobs' to mass rebuild all projects
>> after substantial changes and 'cleanup jobs' to remove old builds from the
>> Package Registry) the core elements needed for initial testing of these
>> scripts are now ready.
>>
>
> As an update, an initial version of the seed job tooling is now ready,
> however testing that tooling requires that dependency information be
> available.
> This requires that the .kde-ci.yml files be populated in repositories.
>
> It would be appreciated if people could please work on getting these files
> populated in Frameworks (as everyone needs those) as well as in their own
> repositories as they are required before we can proceed much further.
>
>
>> For those curious, the results of those initials runs can be found at
>> https://invent.kde.org/groups/teams/ci-artifacts/-/packages
>>
>> Due to the challenges associated with having to handle all of the
>> different forms of build and the versioning of this information, these
>> scripts also represent a radical change in how CI builds will be conducted
>> - with a large part of the configuration of the jobs themselves, including
>> information on project dependencies now shifting to files located within
>> the repository themselves. Those who monitor commits to Frameworks
>> repositories will have noticed the appearance of these '.kde-ci.yml' files
>> in some repositories.
>>
>> To assist in the future rollout of the CI system it would be appreciated
>> if projects could please begin setting up these files within their
>> respective repositories.
>> You can find a template detailing the available options at
>> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml
>>
>> Where possible please avoid overriding the system defaults except where
>> needed by your project (ie. don't just copy the template in full)
>> The defaults mirror the template and can be found at
>> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml
>>
>> In terms of the format of the 'Dependencies' section, please bear in mind
>> the following:
>> - For the 'on' section, the special value '@all' can be used to mean "All
>> platforms" to avoid needing to update the file in the event additional
>> platforms are added in the future
>> - For the 'require' section:
>>   1) Please only include the projects you *explicitly* depend on.
>> Dependencies of your dependencies will be included automatically
>>   2) When specifying a project, you must use the repository path on
>> Gitlab. Legacy project paths (such as kde/workspace/plasma-desktop) are no
>> longer in use and will not work.
>>   3) There are three special values for the branch name - '@same',
>> '@latest' and '@stable' which can be used to refer to the branch/tag of a
>> dependency.
>>   '@same' means the branch name should be the same as that of the
>> project being built and should be used when declaring dependencies among
>> projects in a release group.
>>   '@latest' and '@stable' refer to the corresponding branches defined
>> in the branch-rules.yml file, which can be found in sysadmin/repo-metadata
>>
>> As a general rule, unless you require the absolute latest version of
>> another project in another release unit, it is recommended that you use
>> @stable.
>> Please avoid using explicit branch names unless absolutely necessary.
>>
>> At this time it is expected that the first set of Gitlab CI builds using
>> the new scripts may be conducted for Frameworks within the next week or so,
>> assuming the build of the seed jobs goes according to plan.
>>
>> Once the scripts have been proven successfully for Frameworks, we will
>> look at extending them to projects that depend only on Frameworks and
>> repositories within their release unit and finally will extend them to
>> projects with more complex dependency requirements. It is expected that the
>> switch will be flipped on the Frameworks builds sometime in the 

Re: Issue with translation in Dolphin

[Johnny Jazeix]

Le lun. 31 mai 2021 à 21:47, Albert Astals Cid  a écrit :

> El dilluns, 31 de maig de 2021, a les 21:22:52 (CEST), Johnny Jazeix va
> escriure:
> > Hi,
> >
> > French translation team received a bug (
> > https://bugs.kde.org/show_bug.cgi?id=437856) for a translation issue
> within
> > Dolphin.
> >
> > The issue resides in this code:
> >
> https://invent.kde.org/system/dolphin/-/blob/master/src/kitemviews/kfileitemmodel.cpp#L2182-2194
> > where we expect "'Earlier on' , " to be translated with something
> > like "'translated text' , ".
> >
> > In French, we have translated this single quote to French guillemets "«
> > translated text » , ".
> >
> > Looking at the code, can you confirm it should be kept with single quotes
> > instead? If yes, does having a translator comment would help avoiding the
> > issue?
>
> Yes, the code needs ' since it's passed to QDateTime::toString.
>
> The quotes are not shown to the user, they are used to mark a section as
> "this is text, just pass it though, don't try to do MMM or 
> substitution here".
>
>
Thanks for confirming, I've updated it.

Given that the translation comment is already already very long, what would
> you suggest?
>
>
"Keep the words between single quotes in single quotes"? I'm not sure if
French is an exception here on changing the single quotes sometimes to
guillemets. If this is the only times we have a bug filled for it, maybe
it's not needed to add a new comment.

Cheers,

Johnny


> Cheers,
>   Albert
>
>
> >
> > Cheers,
> >
> > Johnny
> >
>
>
>
>
>

Issue with translation in Dolphin

[Johnny Jazeix]

Hi,

French translation team received a bug (
https://bugs.kde.org/show_bug.cgi?id=437856) for a translation issue within
Dolphin.

The issue resides in this code:
https://invent.kde.org/system/dolphin/-/blob/master/src/kitemviews/kfileitemmodel.cpp#L2182-2194
where we expect "'Earlier on' , " to be translated with something
like "'translated text' , ".

In French, we have translated this single quote to French guillemets "«
translated text » , ".

Looking at the code, can you confirm it should be kept with single quotes
instead? If yes, does having a translator comment would help avoiding the
issue?

Cheers,

Johnny

Re: New Git Hooks Deployed

[Johnny Jazeix]

Hi Ben,

https://build.kde.org/view/Failing/job/Applications/job/kaccounts-integration/job/kf5-qt5%20SUSEQt5.15/lastFailedBuild/console

CMake Error at CMakeLists.txt:50 (include):
include could not find load file:  KDEGitCommitHooks

Side effect or bad ECM minimal version?

Johnny

Le dim. 17 janv. 2021 à 05:45, Ben Cooksley  a écrit :
>
> Hi Community,
>
> This evening we completed the deployment of a significant refactor and rework 
> of the Git hooks that run on Gitlab (invent.kde.org) each time the system 
> receives a push.
>
> This moves us away from the `update` hook to the `pre-receive` hook, ports 
> the hooks to Python 3, refactors a number of parts of the hooks to make them 
> easier to work with and test in the future, and introduces some new 
> functionality.
>
> This new functionality allows for larger changes in certain circumstances to 
> still be notified in a  summarised manner, ensuring that it is still possible 
> to monitor changes to code in our repositories even when bulk imports are 
> taking place from time to time.
>
> As the changes were quite invasive, please let us know if you observe any 
> unusual behaviour.
>
> Many thanks,
> Ben Cooksley
> KDE Sysadmin

Re: New Git Hooks Deployed

[Johnny Jazeix]

Hi Ben,

https://build.kde.org/view/Failing/job/Applications/job/kaccounts-integration/job/kf5-qt5%20SUSEQt5.15/lastFailedBuild/console

CMake Error at CMakeLists.txt:50 (include):
include could not find load file:  KDEGitCommitHooks

Side effect or bad ECM minimal version?

Johnny

Le dim. 17 janv. 2021 à 05:45, Ben Cooksley  a écrit :
>
> Hi Community,
>
> This evening we completed the deployment of a significant refactor and rework 
> of the Git hooks that run on Gitlab (invent.kde.org) each time the system 
> receives a push.
>
> This moves us away from the `update` hook to the `pre-receive` hook, ports 
> the hooks to Python 3, refactors a number of parts of the hooks to make them 
> easier to work with and test in the future, and introduces some new 
> functionality.
>
> This new functionality allows for larger changes in certain circumstances to 
> still be notified in a  summarised manner, ensuring that it is still possible 
> to monitor changes to code in our repositories even when bulk imports are 
> taking place from time to time.
>
> As the changes were quite invasive, please let us know if you observe any 
> unusual behaviour.
>
> Many thanks,
> Ben Cooksley
> KDE Sysadmin

Re: Clarification on licenses and use of MPLv2 in GPLv3+ software

[Johnny Jazeix]

!hi Andreas,

Thank you!

I've read the different threads about the REUSE statements but didn't
took the time to check how much work was needed to apply it to
GCompris.

I've created a task in our backlog to not forget about it:
https://phabricator.kde.org/T13895

Johnny

Le lun. 23 nov. 2020 à 20:23, Andreas Cord-Landwehr
 a écrit :
>
> Hi Johnny,
>
> I read it exactly the same way. So this looks completely fine to me.
>
> Yet, I would suggest to have a look at REUSE compatible license statements,
> which make it much easier to see which files are under which license. Even if
> one should not refer to oneself for reference, here is a starting point how to
> convert to REUSE compatible license statements [1].
>
> Cheers,
> Andreas
>
> [1] 
> <https://cordlandwehr.wordpress.com/2020/09/20/how-to-convert-a-project-to-reuse-compatible-license-statements/>
>
> On Sonntag, 22. November 2020 18:10:44 CET Johnny Jazeix wrote:
> > Hi,
> >
> > GCompris is released under GPLv3+ license. We incorporated the code of
> > a checkers engine under MPL2 licence
> > (https://github.com/shubhendusaurabh/draughts.js).
> >
> > I would like to be sure that it does not change the licence of
> > GCompris (or if we have to ask for a possible relicensing of the
> > library).
> > As I read the documentation in
> > https://www.gnu.org/licenses/license-list.en.html#MPL-2.0, we are
> > doing a "Larger Work" that combines that library with our GPLv3+ code.
> > The library, under our code, will have both licences (we left the
> > LICENSE file besides) and GCompris can be distributed as GPLv3+.
> >
> > Can anyone confirm if my logic is good?
> >
> > Cheers,
> >
> > Johnny
>
>
>
>

Clarification on licenses and use of MPLv2 in GPLv3+ software

[Johnny Jazeix]

Hi,

GCompris is released under GPLv3+ license. We incorporated the code of
a checkers engine under MPL2 licence
(https://github.com/shubhendusaurabh/draughts.js).

I would like to be sure that it does not change the licence of
GCompris (or if we have to ask for a possible relicensing of the
library).
As I read the documentation in
https://www.gnu.org/licenses/license-list.en.html#MPL-2.0, we are
doing a "Larger Work" that combines that library with our GPLv3+ code.
The library, under our code, will have both licences (we left the
LICENSE file besides) and GCompris can be distributed as GPLv3+.

Can anyone confirm if my logic is good?

Cheers,

Johnny

Re: KDiagram - Persistent FTBFS for stable branch on Windows

[Johnny Jazeix]

Hi,

issue is there:
https://invent.kde.org/graphics/kdiagram/-/blob/2.7/src/KChart/CMakeLists.txt#L126
qt5_wrap_cpp(KChart kchart_LIB_SRCS KChartEnums.h) should be
qt5_wrap_cpp(kchart_LIB_SRCS KChartEnums.h)

I'm fixing it.

Johnny


Le lun. 12 oct. 2020 à 16:32, Milian Wolff  a écrit :

> On Montag, 12. Oktober 2020 14:04:06 CEST Dag wrote:
> > mandag den 12. oktober 2020 12.58.36 CEST skrev Dag:
> > > mandag den 12. oktober 2020 12.04.04 CEST skrev Milian Wolff:
> > >> On Montag, 12. Oktober 2020 11:28:45 CEST Ben Cooksley wrote:
> > >>> On Mon, Oct 12, 2020 at 10:24 PM Milian Wolff
> > >>>  wrote: ...
> > >>
> > >> Thanks, but that's looking worse then I expected. I guess
> > >> backporting `35e86e964908ee906dde4f0678c16a838e4712dd` is worth
> > >> a shot.
> > >>
> > >> @Dag: what do you say, should that be safe enough to do?
> > >
> > > No, it will not apply cleanly. I'll do it.
> >
> > Done, but made no difference, still fails.
> > Also tried qt_wrap_cpp -> qt5_wrap_cpp w/o sucess.
> >
> > I'm clueless on windows and can't run any virtual on my machine.
> >
> > Afaics we have this situation, please comment if wrong:
> > - The windows build worked earlier, prior to move to invent.
> > - There has been no changes to the stable branch between the successful
> > build and the failed build.
> > - At the first failing build of stable (oct 6), the code that seems to
> > trigger the failure was the same in stable and unstable except for the
> > qt5_wrap_cpp.
> > - There has been some modernization of unstable, mostly Q_FOREACH() ->
> > for()
> >
> > I'm at loss of even where to start to look, so I hope somebody can point
> a
> > finger in the right direction.
>
> Try to add a src/KChart/KChartEnums.cpp file - I actually wonder how this
> compiles at all on non-windows platforms :)
>
> Also add this line to the .h:
>
> ```
> ~KChartEnums();
> ```
>
> and then this in the .cpp:
>
> ```
> #include "KChartEnums.h"
>
> KChartEnums::~KChartEnums() = default;
> ```
>
> This should ensure that moc knows where to put the include for the
> generated
> code (into KChartEnums.cpp).
>
> Cheers
> --
> Milian Wolff
> m...@milianw.de
> http://milianw.de

Re: Compiling konsole on Windows via craft

[Johnny Jazeix]

Hi,
KPty is mentioned as Pty in the CMakeLists.txt
(https://invent.kde.org/kde/konsole/-/blob/master/CMakeLists.txt#L50).
Hannah mentioned on the KDE-Windows hread that KPty can't be compiled
on Windows yet and is necessary for Konsole, so Konsole can't be
compiled on Windows yet.

Thanks for the quick reply,

Johnny

Le lun. 20 avr. 2020 à 10:52, Konstantin Kharlamov
 a écrit :
>
> On 20.04.2020 11:03, Johnny Jazeix wrote:
> > Hi,
> >
> > there is an issue to compile Konsole on Windows. KPty is not found. A
> > fix for Cantor (https://bugs.kde.org/show_bug.cgi?id=386787) was to
> > remove it from the CMakeLists.txt.
> > Can the same be done for Konsole?
> >
> > Full thread: 
> > https://mail.kde.org/pipermail/kde-windows/2020-April/011157.html
> >
> > Johnny
>
> FWIW, I grepped for kpty over the Konsole sources, and CMakeLists.txt is not 
> among the files where kpty is mentioned. It is however used in the Konsole 
> code.
>
> When I look the fix you mentioned¹, I see they explain in the commit message 
> that components that depend on kpty are simply not built for Windows 
> platform. Offhand, I don't believe this is the case for Konsole.
>
> 1:https://cgit.kde.org/cantor.git/commit/?id=5700cc59da6f8bba503a38ba4c902877206a59cf

Compiling konsole on Windows via craft

[Johnny Jazeix]

Hi,

there is an issue to compile Konsole on Windows. KPty is not found. A
fix for Cantor (https://bugs.kde.org/show_bug.cgi?id=386787) was to
remove it from the CMakeLists.txt.
Can the same be done for Konsole?

Full thread: https://mail.kde.org/pipermail/kde-windows/2020-April/011157.html

Johnny

D27893: Use fallback also on Windows not only mac

[Johnny Jazeix]

jjazeix accepted this revision.
jjazeix added a comment.


  same, good and cleaner. Thank you!

REPOSITORY
  R289 KNotifications

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27893

To: vonreth, broulik, bcooksley, jjazeix, cullmann
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27355: POC: Make kstatusnotifieritem available without dbus

[Johnny Jazeix]

jjazeix added a comment.


  Can we push it as this to fix the Windows builds? It also breaks a few ones 
in https://binary-factory.kde.org/view/Windows%2064-bit/

REPOSITORY
  R289 KNotifications

REVISION DETAIL
  https://phabricator.kde.org/D27355

To: vonreth, bcooksley, jjazeix, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

Re: KDiff3 on macosx

[Johnny Jazeix]

Just the link in case: https://binary-factory.kde.org/job/KDiff3_Nightly_macos/

00:44:13  error:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
for: 
/Users/packaging/Craft/BinaryFactory/macos-64-clang/build/extragear/kdiff3/image-RelWithDebInfo-master/Users/packaging/Craft/BinaryFactory/macos-64-clang/plugins/kf5/parts/kdiff3part.so
(for architecture x86_64) option "-add_rpath
/Users/packaging/Craft/BinaryFactory/macos-64-clang/lib" would
duplicate path, file already has LC_RPATH for:
/Users/packaging/Craft/BinaryFactory/macos-64-clang/lib
...

Le jeu. 27 févr. 2020 à 10:33, Michael Reeves  a écrit :
>
>
> Can someone with a working osx craft setup please look at why KDiff3 is 
> failing on build factory?

Re: KDiff3 on macosx

[Johnny Jazeix]

Just the link in case: https://binary-factory.kde.org/job/KDiff3_Nightly_macos/

00:44:13  error:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
for: 
/Users/packaging/Craft/BinaryFactory/macos-64-clang/build/extragear/kdiff3/image-RelWithDebInfo-master/Users/packaging/Craft/BinaryFactory/macos-64-clang/plugins/kf5/parts/kdiff3part.so
(for architecture x86_64) option "-add_rpath
/Users/packaging/Craft/BinaryFactory/macos-64-clang/lib" would
duplicate path, file already has LC_RPATH for:
/Users/packaging/Craft/BinaryFactory/macos-64-clang/lib
...

Le jeu. 27 févr. 2020 à 10:33, Michael Reeves  a écrit :
>
>
> Can someone with a working osx craft setup please look at why KDiff3 is 
> failing on build factory?

Re: Banning QNetworkAccessManager

[Johnny Jazeix]

Hi,

as Volker said, without any alternative, we can't just ban QNAM.
And even with one, we would need time to implement it (for example,
for GCompris, this part of the code was written by someone who is less
active now, so rewriting it, testing it and be sure it works will take
some time).

Can't we use lxr to find all applications using it, check if they use
it in a good way or not instead?

Johnny


Le mer. 19 févr. 2020 à 10:05, Ben Cooksley  a écrit :
>
> On Wed, Feb 19, 2020 at 9:30 PM Volker Krause  wrote:
> >
> > On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> > > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
> > > > I agree on the problem of QNAM's default, see also
> > > > https://conf.kde.org/en/
> > > > akademy2019/public/events/135 on that subject.
> > > >
> > > > On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> > > > [...]
> > > >
> > > > > Prior to now, i've taken the approach of advertising that
> > > > > QNetworkAccessManager is broken and needs a flag set within
> > > > > applications when used, however unfortunately this seems to have been
> > > > > an ineffective approach and cases of broken behaviour continue to
> > > > > appear (despite this brokeness being known about and advertised since
> > > > > back in the Qt 4.x series when this class was introduced)
> > > > >
> > > > > Therefore, given the Qt Project is unlikely to change their position
> > > >
> > > > > on this, I would like to propose the following:
> > > > The Qt Project is actually in favor of changing at least the redirection
> > > > default to exactly what we want it to be.
> > > > https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, 
> > > > and
> > > > got approval both by Lars and one of the maintainers. It is merely stuck
> > > > in dealing with the unit test fallout in Qt's CI that somebody has to
> > > > take care of. Doesn't immediately help us of course, but claiming Qt is
> > > > unwilling to change this is simply wrong.
> > > >
> > > > > 1) That effective immediately, QNetworkAccessManager and it's children
> > > > > classes be banned and prohibited within KDE software, to be enforced
> > > > > by server side hooks.
> > > > > 2) That we fork QNetworkAccessManager and the associated classes
> > > > > within the appropriate Framework (to be determined), where the
> > > > > defective behaviour can then be corrected.
> > > >
> > > > While this might solve the redirection problem, it brings us yet another
> > > > then unmaintained HTTP implementation next to the one in KIO, which is a
> > > > far bigger problem long term. We need less of those, not more.
> > > >
> > > > To address the problem of people not using the correct defaults, I did
> > > > propose a much less extreme approach in the above mentioned talk at
> > > > Akademy, namely having a KNetworkAccessManager as a sub-class of QNAM in
> > > > a low-tier frameworks that essentially just enables redirects and HSTS.
> > > > QNAM's implementation isn't the problem after all, the defaults are.
> > > >
> > > > Commit hooks warning about QNAM usage might still be a good idea, but 
> > > > as a
> > > > warning only. Hard blocking QNAM-using code would block at least three
> > > > repos I spend a lot of time on currently, none of which even talks to 
> > > > KDE
> > > > servers.
> > > >
> > > > If you need to take more drastic measures against code not doing this
> > > > correctly regardless, you can do that my dropping the server-side
> > > > workarounds. Yes, that would break the affected application possibly, 
> > > > but
> > > > at least it would not cause massive collateral damage for the people
> > > > using this correctly.
> > > >
> > > > It would also help to know where specifically we have that problem, so 
> > > > we
> > > > can actually solve it, and so we can figure out why we failed to fix 
> > > > this
> > > > there earlier.
> > >
> > > Just bringing this up again - it seems we've not had much movement on
> > > this aside from the Wiki page.
> > >
> > > Examining that Qt merge request, it not only is targeted at just Qt
> > > 6.x, it also hasn't had any movement since the start of October 2019 -
> > > 4 months ago.
> > > Given that we are going to be on Qt 5.x for some time, that merge
> > > request can't be considered to be the 'fix' for this issue.
> >
> > The targeting of Qt6 is due to this aiming at dev when that was still Qt 
> > 5.x,
> > but you are right of course, somebody needs to do the work there to drive 
> > this
> > to completion, no matter in which version it will actually land.
>
> Indeed.
>
> >
> > > We need a solution that will ensure software released today doesn't
> > > cause us pain in several years time, because as I illustrated in an
> > > earlier email to this thread, software has a habit of remaining in use
> > > for an extremely long amount of time (August 2014 being the release
> > > date of the Marble versions in question hitting that old URL).
> > >
> > > The easiest 

Re: Banning QNetworkAccessManager

[Johnny Jazeix]

Hi,

as Volker said, without any alternative, we can't just ban QNAM.
And even with one, we would need time to implement it (for example,
for GCompris, this part of the code was written by someone who is less
active now, so rewriting it, testing it and be sure it works will take
some time).

Can't we use lxr to find all applications using it, check if they use
it in a good way or not instead?

Johnny


Le mer. 19 févr. 2020 à 10:05, Ben Cooksley  a écrit :
>
> On Wed, Feb 19, 2020 at 9:30 PM Volker Krause  wrote:
> >
> > On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> > > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
> > > > I agree on the problem of QNAM's default, see also
> > > > https://conf.kde.org/en/
> > > > akademy2019/public/events/135 on that subject.
> > > >
> > > > On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> > > > [...]
> > > >
> > > > > Prior to now, i've taken the approach of advertising that
> > > > > QNetworkAccessManager is broken and needs a flag set within
> > > > > applications when used, however unfortunately this seems to have been
> > > > > an ineffective approach and cases of broken behaviour continue to
> > > > > appear (despite this brokeness being known about and advertised since
> > > > > back in the Qt 4.x series when this class was introduced)
> > > > >
> > > > > Therefore, given the Qt Project is unlikely to change their position
> > > >
> > > > > on this, I would like to propose the following:
> > > > The Qt Project is actually in favor of changing at least the redirection
> > > > default to exactly what we want it to be.
> > > > https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, 
> > > > and
> > > > got approval both by Lars and one of the maintainers. It is merely stuck
> > > > in dealing with the unit test fallout in Qt's CI that somebody has to
> > > > take care of. Doesn't immediately help us of course, but claiming Qt is
> > > > unwilling to change this is simply wrong.
> > > >
> > > > > 1) That effective immediately, QNetworkAccessManager and it's children
> > > > > classes be banned and prohibited within KDE software, to be enforced
> > > > > by server side hooks.
> > > > > 2) That we fork QNetworkAccessManager and the associated classes
> > > > > within the appropriate Framework (to be determined), where the
> > > > > defective behaviour can then be corrected.
> > > >
> > > > While this might solve the redirection problem, it brings us yet another
> > > > then unmaintained HTTP implementation next to the one in KIO, which is a
> > > > far bigger problem long term. We need less of those, not more.
> > > >
> > > > To address the problem of people not using the correct defaults, I did
> > > > propose a much less extreme approach in the above mentioned talk at
> > > > Akademy, namely having a KNetworkAccessManager as a sub-class of QNAM in
> > > > a low-tier frameworks that essentially just enables redirects and HSTS.
> > > > QNAM's implementation isn't the problem after all, the defaults are.
> > > >
> > > > Commit hooks warning about QNAM usage might still be a good idea, but 
> > > > as a
> > > > warning only. Hard blocking QNAM-using code would block at least three
> > > > repos I spend a lot of time on currently, none of which even talks to 
> > > > KDE
> > > > servers.
> > > >
> > > > If you need to take more drastic measures against code not doing this
> > > > correctly regardless, you can do that my dropping the server-side
> > > > workarounds. Yes, that would break the affected application possibly, 
> > > > but
> > > > at least it would not cause massive collateral damage for the people
> > > > using this correctly.
> > > >
> > > > It would also help to know where specifically we have that problem, so 
> > > > we
> > > > can actually solve it, and so we can figure out why we failed to fix 
> > > > this
> > > > there earlier.
> > >
> > > Just bringing this up again - it seems we've not had much movement on
> > > this aside from the Wiki page.
> > >
> > > Examining that Qt merge request, it not only is targeted at just Qt
> > > 6.x, it also hasn't had any movement since the start of October 2019 -
> > > 4 months ago.
> > > Given that we are going to be on Qt 5.x for some time, that merge
> > > request can't be considered to be the 'fix' for this issue.
> >
> > The targeting of Qt6 is due to this aiming at dev when that was still Qt 
> > 5.x,
> > but you are right of course, somebody needs to do the work there to drive 
> > this
> > to completion, no matter in which version it will actually land.
>
> Indeed.
>
> >
> > > We need a solution that will ensure software released today doesn't
> > > cause us pain in several years time, because as I illustrated in an
> > > earlier email to this thread, software has a habit of remaining in use
> > > for an extremely long amount of time (August 2014 being the release
> > > date of the Marble versions in question hitting that old URL).
> > >
> > > The easiest 

Re: Banning QNetworkAccessManager

[Johnny Jazeix]

Hi,

as Volker said, without any alternative, we can't just ban QNAM.
And even with one, we would need time to implement it (for example,
for GCompris, this part of the code was written by someone who is less
active now, so rewriting it, testing it and be sure it works will take
some time).

Can't we use lxr to find all applications using it, check if they use
it in a good way or not instead?

Johnny


Le mer. 19 févr. 2020 à 10:05, Ben Cooksley  a écrit :
>
> On Wed, Feb 19, 2020 at 9:30 PM Volker Krause  wrote:
> >
> > On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> > > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
> > > > I agree on the problem of QNAM's default, see also
> > > > https://conf.kde.org/en/
> > > > akademy2019/public/events/135 on that subject.
> > > >
> > > > On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> > > > [...]
> > > >
> > > > > Prior to now, i've taken the approach of advertising that
> > > > > QNetworkAccessManager is broken and needs a flag set within
> > > > > applications when used, however unfortunately this seems to have been
> > > > > an ineffective approach and cases of broken behaviour continue to
> > > > > appear (despite this brokeness being known about and advertised since
> > > > > back in the Qt 4.x series when this class was introduced)
> > > > >
> > > > > Therefore, given the Qt Project is unlikely to change their position
> > > >
> > > > > on this, I would like to propose the following:
> > > > The Qt Project is actually in favor of changing at least the redirection
> > > > default to exactly what we want it to be.
> > > > https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, 
> > > > and
> > > > got approval both by Lars and one of the maintainers. It is merely stuck
> > > > in dealing with the unit test fallout in Qt's CI that somebody has to
> > > > take care of. Doesn't immediately help us of course, but claiming Qt is
> > > > unwilling to change this is simply wrong.
> > > >
> > > > > 1) That effective immediately, QNetworkAccessManager and it's children
> > > > > classes be banned and prohibited within KDE software, to be enforced
> > > > > by server side hooks.
> > > > > 2) That we fork QNetworkAccessManager and the associated classes
> > > > > within the appropriate Framework (to be determined), where the
> > > > > defective behaviour can then be corrected.
> > > >
> > > > While this might solve the redirection problem, it brings us yet another
> > > > then unmaintained HTTP implementation next to the one in KIO, which is a
> > > > far bigger problem long term. We need less of those, not more.
> > > >
> > > > To address the problem of people not using the correct defaults, I did
> > > > propose a much less extreme approach in the above mentioned talk at
> > > > Akademy, namely having a KNetworkAccessManager as a sub-class of QNAM in
> > > > a low-tier frameworks that essentially just enables redirects and HSTS.
> > > > QNAM's implementation isn't the problem after all, the defaults are.
> > > >
> > > > Commit hooks warning about QNAM usage might still be a good idea, but 
> > > > as a
> > > > warning only. Hard blocking QNAM-using code would block at least three
> > > > repos I spend a lot of time on currently, none of which even talks to 
> > > > KDE
> > > > servers.
> > > >
> > > > If you need to take more drastic measures against code not doing this
> > > > correctly regardless, you can do that my dropping the server-side
> > > > workarounds. Yes, that would break the affected application possibly, 
> > > > but
> > > > at least it would not cause massive collateral damage for the people
> > > > using this correctly.
> > > >
> > > > It would also help to know where specifically we have that problem, so 
> > > > we
> > > > can actually solve it, and so we can figure out why we failed to fix 
> > > > this
> > > > there earlier.
> > >
> > > Just bringing this up again - it seems we've not had much movement on
> > > this aside from the Wiki page.
> > >
> > > Examining that Qt merge request, it not only is targeted at just Qt
> > > 6.x, it also hasn't had any movement since the start of October 2019 -
> > > 4 months ago.
> > > Given that we are going to be on Qt 5.x for some time, that merge
> > > request can't be considered to be the 'fix' for this issue.
> >
> > The targeting of Qt6 is due to this aiming at dev when that was still Qt 
> > 5.x,
> > but you are right of course, somebody needs to do the work there to drive 
> > this
> > to completion, no matter in which version it will actually land.
>
> Indeed.
>
> >
> > > We need a solution that will ensure software released today doesn't
> > > cause us pain in several years time, because as I illustrated in an
> > > earlier email to this thread, software has a habit of remaining in use
> > > for an extremely long amount of time (August 2014 being the release
> > > date of the Marble versions in question hitting that old URL).
> > >
> > > The easiest 

D27355: POC: Make kstatusnotifieritem available without dbus

[Johnny Jazeix]

jjazeix added a reviewer: broulik.

REPOSITORY
  R289 KNotifications

REVISION DETAIL
  https://phabricator.kde.org/D27355

To: vonreth, bcooksley, jjazeix, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27355: POC: Make kstatusnotifieritem available without dbus

[Johnny Jazeix]

jjazeix added a comment.


  thank you!
  I did the same but way worse.
  I think we can at least push this fix to remove all failing jobs then clean 
it up?

INLINE COMMENTS

> CMakeLists.txt:94
>  if (NOT WIN32 AND NOT ANDROID)
>  find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED DBus)
>  find_package(Canberra)

this is not the aim of this diff, but I looked at the code, I found this line 
was duplicated from line 43

REPOSITORY
  R289 KNotifications

REVISION DETAIL
  https://phabricator.kde.org/D27355

To: vonreth, bcooksley, jjazeix
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

Fwd: DBus on Windows - failing Jenkins builds

[Johnny Jazeix]

Hi,

sorry for the direct forward.

TLDR: Notifications uses dbus. On Windows and Mac, there is no dbus so
classes using dbus are not compiled. But KStatusNotifierItem still
uses dbus internally and this causes link error.
Is there a clean and easy way to bypass dbus calls for Windows?

Johnny


-- Forwarded message -
De : Ben Cooksley 
Date: mer. 12 févr. 2020 à 10:17
Subject: Re: DBus on Windows - failing Jenkins builds
To: KDE on Windows 


On Mon, Feb 3, 2020 at 8:15 PM Johnny Jazeix  wrote:
>
> Thank you Hannah for the addition,
>
> It now affects also skrooge and kwordquiz :/ (maybe more soon when
> they will be compiled again).
>
> I can try to find some time during the month and take a look to add
> these ifdef, if nobody fixes it before.

Another option is to raise this on KDE Frameworks Devel, as someone
there may know of an easy way to shortcut the D-Bus code in KSNI.

Cheers,
Ben

>
> Johnny
>
> Le dim. 2 févr. 2020 à 12:46, Hannah von Reth  a écrit :
> >
> > I had another look.
> > It looks like we need to add a couple of ifdefs to 
> > https://github.com/KDE/knotifications/blob/master/src/kstatusnotifieritem.cpp
> > There is no point in using dbus on Windows or mac here, as there is no 
> > desktop service that could receive it
> >
> >
> > On 01.02.20 18:36, Ben Cooksley wrote:
> >
> > On Sun, Feb 2, 2020 at 1:53 AM Johnny Jazeix  wrote:
> >
> > The applications link to KF5Notifications.lib library, the issue is
> > that this one does not compile KStatusNotifierItem class because it's
> > in a conditional if in the CMakeLists.txt of KF5Notifications.
> >
> > Which is the correct behaviour as we want a version without D-Bus.
> >
> > Unfortunately though that means every KDE application that wants to
> > provide a system tray icon will fail to compile, as we use KSNI for
> > that. For systems that don't mind having dbus around at runtime, it
> > isn't an issue as KSNI will fallback to QSystemTrayIcon. We of course
> > don't want DBus at all (even at runtime), so it seems to me that the
> > necessary fix is for KSNI on Windows to skip all the DBus stuff and
> > just provide it's wrapper functionality.
> >
> > The same should probably apply on macOS.
> >
> > Thoughts?
> >
> > Cheers,
> > Ben
> >
> > Le sam. 1 févr. 2020 à 13:15, Hannah von Reth  a écrit :
> >
> > Directly linking to KStatusNotifierItem sounds wrong.
> >
> > It should probably use the normal knotifications api.
> >
> >
> > Cheers,
> >
> > Hannah
> >
> >
> > On 01.02.20 12:49, Johnny Jazeix wrote:
> >
> > Le sam. 1 févr. 2020 à 09:57, Ben Cooksley  a écrit :
> >
> > On Sat, Feb 1, 2020 at 9:51 PM Johnny Jazeix  wrote:
> >
> > Hi,
> >
> > Hi Johnny,
> >
> > There are some builds in Jenkins that fail because of unresolved
> > external symbol of KStatusNotifierItem class (and let's be fair, I
> > don't like failing Jenkins).
> > After digging a bit, it is due to the fact that KNotifications is
> > built without dbus support:
> > https://cgit.kde.org/knotifications.git/tree/CMakeLists.txt#n42
> > meaning kstatusnotifieritem.cpp is not compiled:
> > https://cgit.kde.org/knotifications.git/tree/src/CMakeLists.txt#n24
> >
> > Aha. I had seen a few of these KSNI symbol failures, so it's nice to
> > know why they're occurring.
> >
> > However dependencies (drkonqi and ruqola if I'm not wrong), don't have
> > a condition on Windows for DBus use and directly use the
> > KStatusNotifierItem class.
> >
> > I'm not sure on the support of DBus on Windows and what is the right
> > direction to go:
> > * either enable dbus on KNotifications for Windows (if it is supported).
> > * or disable dbus on Windows on programs that uses it (drkonqi and ruqola)..
> >
> > Given that D-Bus doesn't really belong on Windows, doesn't bring us
> > much in the way of benefits there (as users are using just a single
> > application in many cases), and has tended to cause false positives
> > with anti-malware products, i'd suggest we follow the path of
> > disabling dbus support.
> >
> > Of course that brings up the question of whether KSNI should exist at
> > all on Windows. If memory serves it provides support for system tray
> > icons, in which case it probably should just wrap around the
> > appropriate Qt classes (for which I think fallback code already
> > exists?) and not compile any of the D-Bus stuff.
> >
> > Thoughts?
> >
> > It may be something to discuss on kde-devel (or directly with the
> > corresponding teams) because I don't know much about the use of the
> > library in the applications.
> >
> > KStatusNotifierItem is not used a lot on drkonqi:
> > https://github.com/KDE/drkonqi/search?q=statusnotifier_q=statusnotifier
> > so it should not be complicated to bypass it on Windows but it seems
> > to require more efforts for ruqola.
> >
> > Johnny
> >
> >
> > Johnny
> >
> > Do you have any input on this?
> >
> > Johnny
> >
> > Cheers,
> > Ben

Re: Banning QNetworkAccessManager

[Johnny Jazeix]

[...]

> All of the places where we have actively hit this issue have already
> been fixed (Marble and Attica come immediately to mind, not sure if
> GCompris fixed their code).
>

I took a quick look and we use some code to handle redirection:
https://github.com/gcompris/GCompris-qt/blob/master/src/core/DownloadManager.cpp#L502
It's not the same code as mentioned by David in
https://community.kde.org/Policies/API_to_Avoid#QNetworkAccessManager,
I'll update the code tonight.

Johnny

> The rest continue to be sleeping timebombs which we will only discover
> when we change something on the server side and put in place a
> redirect. They may never be triggered, or they could be triggered next
> week. Even if we fix the code now, due to LTS distributions and people
> using software for far longer than they should, it will take years for
> the fixes to fully reach user systems.
>
> To illustrate how long this takes, Marble moved from using
> http://files.kde.org/marble/maps/ to https://maps.kde.org/ back in
> January 2016. Four years later, we still get 13,000 hits to paths
> under the old URL every day. The version numbers sent by Marble as
> part of these requests indicate that some of them are from the version
> released with KDE 4.14 which was released back in August 2014
> (fortunately this code path was fixed to follow redirects prior to
> that release)
>
> >
> > Regards,
> > Volker
>
> Cheers,
> Ben

Re: Banning QNetworkAccessManager

[Johnny Jazeix]

[...]

> All of the places where we have actively hit this issue have already
> been fixed (Marble and Attica come immediately to mind, not sure if
> GCompris fixed their code).
>

I took a quick look and we use some code to handle redirection:
https://github.com/gcompris/GCompris-qt/blob/master/src/core/DownloadManager.cpp#L502
It's not the same code as mentioned by David in
https://community.kde.org/Policies/API_to_Avoid#QNetworkAccessManager,
I'll update the code tonight.

Johnny

> The rest continue to be sleeping timebombs which we will only discover
> when we change something on the server side and put in place a
> redirect. They may never be triggered, or they could be triggered next
> week. Even if we fix the code now, due to LTS distributions and people
> using software for far longer than they should, it will take years for
> the fixes to fully reach user systems.
>
> To illustrate how long this takes, Marble moved from using
> http://files.kde.org/marble/maps/ to https://maps.kde.org/ back in
> January 2016. Four years later, we still get 13,000 hits to paths
> under the old URL every day. The version numbers sent by Marble as
> part of these requests indicate that some of them are from the version
> released with KDE 4.14 which was released back in August 2014
> (fortunately this code path was fixed to follow redirects prior to
> that release)
>
> >
> > Regards,
> > Volker
>
> Cheers,
> Ben

D26691: Optimize code when dropping files into the desktop

[Johnny Jazeix]

jjazeix added a comment.


  Compilation fails: 
https://build.kde.org/view/Failing/job/Plasma/job/plasma-framework/job/kf5-qt5%20SUSEQt5.12/288/console
  Missing the new file in the CMakeLists.txt?

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D26691

To: trmdi, #plasma, mart, broulik, #vdg, davidedmundson
Cc: jjazeix, davidedmundson, anthonyfieroni, #plasma, kde-frameworks-devel, 
LeGast00n, GB_2, michaelh, ngraham, bruns

Re: Banning QNetworkAccessManager

[Johnny Jazeix]

[...]

> All of the places where we have actively hit this issue have already
> been fixed (Marble and Attica come immediately to mind, not sure if
> GCompris fixed their code).
>

I took a quick look and we use some code to handle redirection:
https://github.com/gcompris/GCompris-qt/blob/master/src/core/DownloadManager.cpp#L502
It's not the same code as mentioned by David in
https://community.kde.org/Policies/API_to_Avoid#QNetworkAccessManager,
I'll update the code tonight.

Johnny

> The rest continue to be sleeping timebombs which we will only discover
> when we change something on the server side and put in place a
> redirect. They may never be triggered, or they could be triggered next
> week. Even if we fix the code now, due to LTS distributions and people
> using software for far longer than they should, it will take years for
> the fixes to fully reach user systems.
>
> To illustrate how long this takes, Marble moved from using
> http://files.kde.org/marble/maps/ to https://maps.kde.org/ back in
> January 2016. Four years later, we still get 13,000 hits to paths
> under the old URL every day. The version numbers sent by Marble as
> part of these requests indicate that some of them are from the version
> released with KDE 4.14 which was released back in August 2014
> (fortunately this code path was fixed to follow redirects prior to
> that release)
>
> >
> > Regards,
> > Volker
>
> Cheers,
> Ben

Licence of GCompris in ubuntu snaps

[Johnny Jazeix]

Hi,
I just installed a fresh ubuntu and noticed that the GCompris licence
in the snap package was "Proprietary". After some search, I think it's
because it's set to "unset" in the snap package:
https://snapcraft.io/gcompris

Does anyone know who should I contact to set it to GPLv3+? There is
also a "Is there a problem with gcompris? Report this app" button that
I can contact if nobody knows.

Thanks,

Johnny

D19016: Update Android toolchain files to reality

[Johnny Jazeix]

jjazeix added a comment.


  In D19016#420246 , @apol wrote:
  
  > Applications can still override it, note it's a default.
  >  Also note this: 
https://developer.android.com/distribute/best-practices/develop/target-sdk
  
  
  Ok, good for me :).
  Thanks for the link!

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D19016

To: vkrause, apol
Cc: jjazeix, apol, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, 
bruns

D19016: Update Android toolchain files to reality

[Johnny Jazeix]

jjazeix added inline comments.

INLINE COMMENTS

> Android.cmake:150
>  set_deprecated_variable(CMAKE_ANDROID_ARCH_ABI ANDROID_ABI "armeabi-v7a")
> -set_deprecated_variable(CMAKE_ANDROID_API ANDROID_API_LEVEL "14")
> +set_deprecated_variable(CMAKE_ANDROID_API ANDROID_API_LEVEL "21")
>  

Sorry, I'm a bit late, but would it be possible to put 16 as minimum here? Some 
projects (GCompris at least) do not use KF5 and would like to target lower API 
levels.
I can do the diff/commit to change it if necessary

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D19016

To: vkrause, apol
Cc: jjazeix, apol, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, 
bruns

D15643: Android: Allow passing a relative path as the apk dir

[Johnny Jazeix]

jjazeix accepted this revision.
jjazeix added a comment.
This revision is now accepted and ready to land.


  works fine, sorry for the doubt, I probably badly applied it last time.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  arcpatch-D15643

REVISION DETAIL
  https://phabricator.kde.org/D15643

To: apol, #frameworks, #gcompris, jjazeix
Cc: jjazeix, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D15643: Android: Allow passing a relative path as the apk dir

[Johnny Jazeix]

jjazeix added a comment.


  Unfortunately, this does not work. The tmpAndroid folder is created in the 
build folder after running cmake, so it's not available before:
  
Cannot find tmpAndroid//AndroidManifest.xml according to ANDROID_APK_DIR.
tmpAndroid/ GCompris
  
  Call Stack (most recent call first):
  
/opt/cmake/share/cmake-3.11/Modules/CMakeDetermineSystem.cmake:94 (include)
CMakeLists.txt:4 (project)

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D15643

To: apol, #frameworks, #gcompris
Cc: jjazeix, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D15643: Android: Allow passing a relative path as the apk dir

[Johnny Jazeix]

jjazeix added a comment.


  Seems good to me at first sight, I'll try it as soon as possible

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D15643

To: apol, #frameworks, #gcompris
Cc: jjazeix, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

Re: Problem in GCompris unit testing

[Johnny Jazeix]

Hi,
the exercice is a theorical one, not a practical one ("For balancebox
activity, how will you approach the unit test for this specific activity,
what would you test and how?" for those who wonder).
This issue is probably the only difficult one the student will have to
search for during gsoc so it would be better to later dig more yourself
before asking for help and more rewarding.

Johnny

2018-04-03 6:32 GMT+02:00 Himanshu Vishwakarma :

> Hi,
>
> Currently, I am working on GSoC exercise as given by the mentors. I
> facing some problem in CMAKE while compiling the qml test. My Question
> is:
>
> How to import the activity libraries in the test directory? So that it
> can use in the test.
>
> I write CMakeLists.txt file is something like this:
> https://paste.kde.org/pkhgy85pv
> when I import the files which I going to be tested in our test file,
> It gives the error in the followings lines of the imported file.
>
> import QtQuick 2.6
> import GCompris  1.0
> import Box2D 2.0 as Box2D
>
> when compile, it gives the error like this: Error:
> ~/gcompris-qt/src/activities/balancebox/balancebox.js:30,1: module
> "QtQuick" version 2.6 is not installed OR module "GCompris" is not
> installed OR module "Box2D" is not installed.
> Whereas all the files of the GCompris are importing QtQuick 2.6 &&
> GCompris 1.0 and it compiles successfully.
>
> Currently, I am using the Qt5 version 5.6.1 and the following methods
> for importing in the file like this:
> import "../../src/activities/balancebox"
> import "../../src/activities/balancebox.js" as Activity
> Correct me if I am wrong.
>
> please help me !! So that I can compile the test
> --
> Regards,
> Himanshu Vishwakarma
>

Re: KDE and Google Summer of Code 2018

[Johnny Jazeix]

Hi,

on GCompris side, we hope/plan to mentor 2 students like last year. I
updated the page to add one more task.

Regarding the events: this year, we were planning to skip SoK to focus more
on GCi and GSoC, having the 3 events is too consuming and do not allow us
to progress on our main tasks. There was a bit of change due to the fact
that it was GCi that was skipped but the main point is still there, we
don't have enough time/resource to handle the 3 events.

Johnny


2018-01-15 1:39 GMT+01:00 Valorie Zimmerman :

> I'm very discouraged to see so little movement on this. After skipping GCi
> this past fall, are we now also considering skipping GSoC? Or downsizing
> the number of students we are mentoring?
>
> Without Ideas we will not get students. More important, we must complete
> the Org application soon, and the Ideas page is the core of that
> application.
>
> This is good for your team and your project, in the long run. It brings in
> new contributors and fresh ideas.
>
> If you need some guidance, please read https://google.github.io/
> gsocguides/mentor/defining-a-project-ideas-list.html
>
> I should have linked to it for the last email.
>
> Valorie
>
> On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman <
> valorie.zimmer...@gmail.com> wrote:
>
>>
>> Hello GSoC mentors, and teams supporting mentors,
>>
>> TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas; read
>> https://community.kde.org/GSoC. Now.
>>
>> Every year, we've asked for more time to get ramped up for GSoC, and so
>> now is the time for organizations to apply[1]. We have begun to write our
>> application, and  that means that our Ideas page needs to be filled NOW,
>> because that is the prime consideration for the GSoC team once the Org
>> Applications deadline has passed.
>>
>> The quality of our ideas and the guidance they give our students are the
>> most important part of our application. Please begin filling in your ideas
>> now if you have not already, and ensure that that page is comprehensive,
>> accurate and attractive. Including screenshots and other images is allowed,
>> if it enriches the idea for a project. *Please ensure complete information
>> about how to contact the team*; this is crucial.
>>
>> Also, take a look at the landing page https://community.kde.org/GSoC.
>> Experienced mentors agree that:
>>
>> 1. commits must be made before the student proposal is submitted, and
>> linked on that proposal, and
>>
>> 2. that regular communication from the student must be initiated by the
>> student at least weekly, and we expect daily or nearly daily communication
>> with the team in a more informal way.
>>
>> Be sure to point students to that information, as this should lower the
>> number of proposals, while raising the quality.
>>
>> 1. https://developers.google.com/open-source/gsoc/timeline
>>
>> PS: If your team has an Idea, ensure that you have mentors for it, and
>> that those mentors are subscribe to KDE-Soc-Mentor list. Remove any ideas
>> without mentors available, please. Now, before you forget!
>>
>> Valorie
>>
>
>
> --
> http://about.me/valoriez
>

Re: KDE and Google Summer of Code 2018

[Johnny Jazeix]

Hi,

on GCompris side, we hope/plan to mentor 2 students like last year. I
updated the page to add one more task.

Regarding the events: this year, we were planning to skip SoK to focus more
on GCi and GSoC, having the 3 events is too consuming and do not allow us
to progress on our main tasks. There was a bit of change due to the fact
that it was GCi that was skipped but the main point is still there, we
don't have enough time/resource to handle the 3 events.

Johnny


2018-01-15 1:39 GMT+01:00 Valorie Zimmerman :

> I'm very discouraged to see so little movement on this. After skipping GCi
> this past fall, are we now also considering skipping GSoC? Or downsizing
> the number of students we are mentoring?
>
> Without Ideas we will not get students. More important, we must complete
> the Org application soon, and the Ideas page is the core of that
> application.
>
> This is good for your team and your project, in the long run. It brings in
> new contributors and fresh ideas.
>
> If you need some guidance, please read https://google.github.io/
> gsocguides/mentor/defining-a-project-ideas-list.html
>
> I should have linked to it for the last email.
>
> Valorie
>
> On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman <
> valorie.zimmer...@gmail.com> wrote:
>
>>
>> Hello GSoC mentors, and teams supporting mentors,
>>
>> TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas; read
>> https://community.kde.org/GSoC. Now.
>>
>> Every year, we've asked for more time to get ramped up for GSoC, and so
>> now is the time for organizations to apply[1]. We have begun to write our
>> application, and  that means that our Ideas page needs to be filled NOW,
>> because that is the prime consideration for the GSoC team once the Org
>> Applications deadline has passed.
>>
>> The quality of our ideas and the guidance they give our students are the
>> most important part of our application. Please begin filling in your ideas
>> now if you have not already, and ensure that that page is comprehensive,
>> accurate and attractive. Including screenshots and other images is allowed,
>> if it enriches the idea for a project. *Please ensure complete information
>> about how to contact the team*; this is crucial.
>>
>> Also, take a look at the landing page https://community.kde.org/GSoC.
>> Experienced mentors agree that:
>>
>> 1. commits must be made before the student proposal is submitted, and
>> linked on that proposal, and
>>
>> 2. that regular communication from the student must be initiated by the
>> student at least weekly, and we expect daily or nearly daily communication
>> with the team in a more informal way.
>>
>> Be sure to point students to that information, as this should lower the
>> number of proposals, while raising the quality.
>>
>> 1. https://developers.google.com/open-source/gsoc/timeline
>>
>> PS: If your team has an Idea, ensure that you have mentors for it, and
>> that those mentors are subscribe to KDE-Soc-Mentor list. Remove any ideas
>> without mentors available, please. Now, before you forget!
>>
>> Valorie
>>
>
>
> --
> http://about.me/valoriez
>