Update 4.4.0.58→4.4.0.64 & unify formatting

[Olf0]

Reference: https://forum.sailfishos.org/t/release-notes-vanha-rauma-4-4-0/10656#update-version-history-1

[CLAassistant]

All committers have signed the CLA.

[Olf0]

Motivation

The fact that only SailfishOS 4.4.0.58 is listed as a stop release, but not 4.4.0.64 has already created confusion at FSO, even though the release note are quite clear in my understanding: https://forum.sailfishos.org/t/release-notes-vanha-rauma-4-4-0/10656#update-version-history-1

License

This contribution is submitted in accordance to the CC-BY-NC-SA 4.0 license, as noted at Releases|Sailfish OS Documentation (https://docs.sailfishos.org/Releases/) on 2022-06-06.

CLA / CLA needs fixing!

• I am willing to sing Jolla's CLA (version: 2021-11-12), granted the dubious "CLA assistant" run by Cloudflare and SAP access to my e-mail address at GitHub, but when it (in an additional step) also requested read access to all the GitHub-teams I am part of, plus write access to my Gists etc., I bailed out and closed the browser tab: This is a no-go, please fix it.
  → Researched: This is the issue described at cla-assistant wants too many authorizations cla-assistant/cla-assistant#78, Too wide GH API permissions required just to sign a CLA cla-assistant/cla-assistant#97, Disabled cookies lead to - Overbearing permissions required to sign CLA cla-assistant/cla-assistant#566, cla-assistant requires excessive permissions cla-assistant/cla-assistant#810, It works rather slowly, and it wants excessive write access  cla-assistant/cla-assistant#863 etc.
• When trying again, I was not asked anything after confirming the terms & conditions check-box and hitting "Sign in with GitHub to agree" at the bottom of the "CLA assistant", but it reported success! This opaque behaviour is also a no-go, please fix it.
  → Researched: This is the issue described at Signing in with github "signs" the CLA cla-assistant/cla-assistant#760.
• Slightly in panic, I looked up in my GitHub account settings, which access rights were indeed granted by these two remarkably weird actions in this strange CLA singing process: It turned out to be read access to my e-mail address, only.

Hence please consider using the contributor-assistant/github-action instead, which provides these advantages (compared to the technically dreaded "CLA assistant"):

• decentralizing the database of contributors
• fully integrated with github environment
• no UI is required
• no need to grant any permission/scope

[llewelld]

The changes here look good to me. There is the issue of alignment highlighted by @rainemak, which it would be nice to have fixed, but given this is an existing glitch my personal feeling, in the interests of moving things forward, is that we could do it as a separate commit afterwards.

[rainemak]

The changes here look good to me. There is the issue of alignment highlighted by @rainemak, which it would be nice to have fixed, but given this is an existing glitch my personal feeling, in the interests of moving things forward, is that we could do it as a separate commit afterwards.

Separate commit works for me. Could you @Olf0 rebase this one?

[llewelld]

Hence please consider using the contributor-assistant/github-action instead

Thanks for flagging up these issues with the CLA @Olf0, and sorry that you experienced issues. I've logged an internal issue about it, including your suggestion to use contributor-assistant/github-action instead. That doesn't guarantee it'll get changed, but at least increases the chance it'll get properly looked at.

[llewelld]

Still LGTM.

[Olf0]

I have been away on a holiday. I will try to work through the responses for other PRs the next couple of days.

[Olf0]

@rainemak, thank you very much for merging this PR, despite the fact that it consisted of two commits after addressing the additional changes you requested outside of my original changeset in a second commit.

Note that I never have managed to properly rebase by using GitHub's web-frontend (as you requested), even though the function exists there and I experimented with it few times, despite knowing how rebasing works in theory and practice when using the git command line tool on a locally cloned repository. But for small changesets I always do prefer to use GitHub's web-frontend to clone ("fork") a git-repository, employ changes and submit a PR, because it is much easier, quicker and provides some additional benefits (i.e. here, displaying the zero width spaces). Consequently I do not have a locally cloned git-repository for any of my contributions to SailfishOS, because the all were tiny.

Hence I suggest to loosen Jolla's contributor rule that a PR shall comprise a single commit to "an externally contributed PR initially must comprise a single commit, but each round of changes requested by sailors may be addressed by an additional commit". This would enable contributors to perform all the work at GitHub's web-frontend (i.e., cease to enforce a specific workflow using a locally cloned git-repository). Alternatively a pointer to some guide how to properly use the rebase function of GitHub's web-frontend would be much appreciated (e.g., in Jolla's contributor guidelines), as I failed to find one despite searching for it.