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: [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: 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: 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!

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: 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
>

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: 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: 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: 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]

[...]

> 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: 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
>