Update README.md

[Olf0]

No description provided.

[b100dian]

One link needs updating, otherwise this is god, thanks Olf0

[b100dian]

nit: additional space

[Olf0]

Well, this is done on purpose:

• Background: "Modern" American English writing style is to use double space after a full stop at the end of a sentence.
  • Well it is nor really that "modern", I also came across typewriter written texts from the 1940s utilising this style.
  • I usually do prefer British English (spelling, grammar, style), but the double space does have a couple of advantages:
    • It clearly marks the end of a sentence, because a full stop sign is also used for other purposes: "e.g. & i.e.", "etc." and other abbreviations (e.g., "approx.") etc. In case of "etc." it often is also the end of the sentence (one does not spell "etc.." then), but not necessarily so, hence using a double space or not unambiguosly marks either case.
    • Especially when using monospaced fonts (from typewriters to what today is usually used for displaying source code), it makes it a lot easier to identify the end of each sentence.
    • This writing style became a lot more common among nerds with the advent of emails, because back then emails always were using monospaced fonts. This still is a common style used at, e.g., the LKML (Linux Kernel Mailing List).
  • For Markdown, the double spaces are only visible in the source code. When an MD file is rendered, all multiple, consecutive spaces are displayed as a single space (IIRC HTML renderers do the same).
• The original text had a some sentences followed by double spaces and some without: I merely made that consistent, deciding to use double spaces after each sentence, if another one follows.
• This MR has "Allow edits by maintainers" checked, hence you may change that, if you do not like this style of formatting the Markdown source code. But if you do that, please do it consistently throughout the whole text (there are at least three more double spaces).

If you are O.K. with this (due to the reasoning here), just hit the "Resolve conversation" button and merge.
If not, please hit the "Resolve conversation" button, adapt it as you like and merge then. Or the other way around: Hit the "Resolve conversation" button, merge and adapt as you like.

[b100dian]

Didn't know all that:)

[Olf0]

Sorry, I should not have explicitly re-requested a review, because you already provided one and above point can be resolved by the conversation (and "Resolve conversation" button) there: I just was too quick hitting the "Request review" button without thinking.

[Olf0]

@b100dian, as you seem to be "well on the way" / "almost there" to resurrecting the full Patchmanager 3 functionality for SailfishOS 4 and you have commit rights here at the PM3 source repo, I have a couple of questions, how you plan to proceed and how I may support that.
Side note: I am abusing this closed merge request for this half-private, but publicly visible conversation, because it is convenient and somewhat related.

1. Structural:
   • Do you want to fill the maintainer role for Patchmanager for SailfishOS?
     As far as I understand, @CODeRUS does not want to maintain PM any more, thus that role is currently vacant.
     While this implies some responsibility (only socially and maybe emotionally, but sure not formally; if you temporally lack the time to care, you simply don't, as CODeRUS sometimes did), this does not mean you have to to all the work, but you should coordinate it.
   • Do you have access to the Patchmanager 3.0 page at Openrepos so you can deploy new RPMs there? Probably not, because "projects" at Openrepos are linked to a single maintainer AFAIK, but maybe @CODeRUS is still willing to do that.
     Setting up a new project page at Openrepos would be that alternative way.
     Either way, if you control a PM "project" at Openrepos, I could support you in maintaining that page and providing answers to simple questions from users there. I already gathered a couple of enhancements for the Openrepos page (similar to the MR above for the README.md here) in issue #9 (from 2017 / 2018).
   • BTW, there is also a Patchmanager 3 project at Transifex (https://www.transifex.com/coderus/patchmanager3/), which should be synchronised with this project at GitHub when new strings are introduced here or new translations were carried out at Transifex.
     I do not know the technical processes in detail, and if you need maintainer access at Transifex for that (I only use Transifex as a translator), but you might.
   • I also wonder how @CODeRUS considers the future maintenance of https://coderus.openrepos.net/pm2/projects/ to be carried out.
2. Technical
   As you and nephros discussed, /etc/firejail/whitelist-common.local needs to be patched when deploying Patchmanager.
   AFAIU this should be done per RPM spec file, because Patchmanager is not able to patch files outside its Firejail jail, before that patch is applied.

[b100dian]

Hi @Olf0, I think we cross-posted around the same time.
Thanks for your support - and have patience with us while we wrap our heads around all these:)!
I am fully supportive of public conversations around this.

1. Structural
   • yes, this is the plan - to fill in the gap, and not by oneself but through a team of people.
   • I will probably publish a separate package on openrepos, for SFOS 4.0 and on.
   • This is a very good point, I need to ramp up in using transifex too and maybe request access. Do you already have?
   • I don't know, let's take it one at a time. I do not know where the sources are for that web project.
2. Technical
   • That's exactly the first goal:)

I am abusing this closed merge request for this half-private, but publicly visible conversation, because it is convenient and somewhat related.

We still need to find a way for discussing in a more 'organized' manner.

[Olf0]

Transifex

I need to ramp up in using transifex too and maybe request access. Do you already have?

Well, I have a user account at Transifex and access to the "projects" as a translator for the "organisation" (in Transifex's / Atlassian's parlance) Coderus: https://www.transifex.com/coderus/
You question triggered me to look up the role definitions at Transifex: https://docs.transifex.com/teams/understanding-user-roles
In short: "We recommend making developers on your team either Maintainers or Admins." For the detailed access rights, see the tables at the end of this page.

As it requires the admin role to be able to fully handle an "organisation's" projects and there can be multiple Admins for an "organisation", I kindly ask @CODeRUS to provide me with an admin role for the "organisation" Coderus at Transifex: I am willing to manage the access rights and the projects maintenance (but only at Transifex's web-frontend) of the "organisation" Coderus. My account name is also "olf" at Transifex. My first action will be to provide another person with admin rights (e.g. you, @b100dian, if you do not mind, or anybody else I trust, e.g. @Ancelad), so it does not fully depend on me being available. My second action would be to evaluate which projects at Transifex can be archived (e.g. PM2).

I also started an own "organisation" olf (https://www.transifex.com/olf/) with an archived project at GitHub to "translate" (crypto-sdcard_sbj), to have a playground to see how things work, to avoid misstepping in an admin role for the "organisation" Coderus.

Website https://coderus.openrepos.net/pm2 with all sub-pages

I also wonder how @CODeRUS considers the future maintenance of https://coderus.openrepos.net/pm2/projects/ to be carried out.

I don't know, let's take it one at a time. I do not know where the sources are for that web project.

To me the dialogue you had with @CODeRUS at FSO is not conclusive (i.e., I do not really understand what Andrey's suggestion is, how to proceed): https://forum.sailfishos.org/t/contribution-required-my-orphaned-projects/6799/16 ff.
@CODeRUS, please copy and paste the existing code, which is running at https://coderus.openrepos.net/pm2 and its sub-pages to a GitHub project or a GitHub gist (and as mentioned above, the same for https://coderus.openrepos.net/whitesoft/sailversion), so we can maintain / re-establish these services.

Side note / idea: It would be really nice to utilise a separate GitHub project for Patchmanager's web-catalog, e.g. https://github.com/sailfishos-patches/web-catalog/ : Its README.md, a gist or its wiki could be used for list of available Patches, plus the web-catalog Patches would gain a place to file issues for them.
Still it would be nice to understand how the automatisms at https://coderus.openrepos.net/pm2 were implemented, in order to try to create something similar.

Patchmanager developers exchange

We still need to find a way for discussing in a more 'organized' manner.

Yes, I also pondered a bit about that and IMO made some progress:

• No chat platform (IRC, Telegram, Jabber etc.)
  • Chats are volatile (unless explicitly recorded)
  • Chats are closed (unless explicitly published)
  • Chats are opaque to outsiders (unless explicitly recorded and published)
  • Chats are not searchable (thus not transparent)
• A wiki could work for coordinating developers, but is basically the wrong tool.
  But a wiki is available here at GitHub.
• Looking at the other tools GitHub offers (tasks and projects): They are aimed at distributing work and do offer surprisingly slim functionality IMO.
  Hence they are also not really suitable to foster communication.
• A forum (thread) is IMO the best tool to communicate and organise a Patchmanager developers team in an open and transparent manner.
  I think there are only two forum platforms which fit well: FSO and TMO
  • FSO is controlled by Jolla, which regularly (but rarely) makes sudden and harsh decisions.
    Also Andrey's suggestion to move the extant Patchmanager discussion thread to FSO did only receive a single upvote.
  • TMO has been a stable platform (technically, organisationally, socially (moderation), by functionality (the search tools do find appropriate things)) for more than a decade (in contrast to TJC and FSO).
    • There already is the classic Patchmanager thread there, which is aimed at Patchmanager users and Patch developers, because there was only a single Patchmanager developer in the past: Basil (SfietKonstantin) for the original Patchmanager and Coderus for Patchmanager 2 and 3. It is titled "maemo.org → Talk → OS / Platform → SailfishOS → [WIP] App / Tweak: patchmanager a system-wide patching system + homescreen tweak"

Thus my suggestion is that I open a new thread "maemo.org → Talk → OS / Platform → SailfishOS → [Patchmanager and Patches] Developer's exchange", when I have a introduction written, which designates this new thread to developers of Patchmanager and Patches for Patchmanager. I would also denote that the old thread is still there for users of Patchmanager and issue reports for Patches from the web-catalog (because there is no other place for this; see above for an idea how to resolve this; RPM Patches have their Openrepos page for discussions / issue reports, plus often a Git{hub|lab} project with an issue tracker).
That introduction should also denote why this has become necessary (basically pointing to Coderus' message "Contribution required. My orphaned projects" at FSO), what the new development model for Patchmanager is (a team), but also where and how development takes place and issues can be reported. Hence I have a few questions, before I start to draft such a introductory message:

• Do you have full control over this repository, so this can stay as the development platform? This definitely is preferable, primarily for continuity's sake. But if we have to use a fork of it in order to be able to perform administrative tasks (e.g., clean up the wiki (with its long outdated information), add new maintainers etc.) then this should be rather done soon.
• What is your nickname at TMO (if you already have an account there)?
  b100dian and vlagged yielded nothing.
• Is it O.K., if I join your Patchmanager team (with @nephros), but primarily for organisational and promotional (i.e., writing texts) aspects?
  My technical know-how is limited to Unix, shell programming, manual RPM packaging, systemd, udisks, polkit, a little C, but no modern programming languages (C++, JavaScript, Python, QML etc.).
• What does @nephros think about this, especially opening a new TMO thread?

P.S.: Side note / "for something completely different"
Before you release a SFOS 4 compatible Patchmanager at Openrepos (likely in a different repository, as you already mentioned), I strongly suggest to increase its version number to 3.1.x (from 3.0.x) to denote that some things have changed.
As stated I am sure willing to design a front-page for it (which would likely follow the basic style of my software pages there, e.g. sfos-upgrade).

[b100dian]

Hi @Olf0,
I'll try to answer the last part of your message for now:

• "Do you have full control over this repository" I don't have full control, I can merge pull requests. I was planning to branch out patchmanager3.1 - had the same idea as you (plus, pm4 is taken:) - but I can't yet change the default branch. I consider this as a non blocker for the goal to have openrepos 3.1 version, can be handled later.
• "What is your nickname at TMO"? https://talk.maemo.org/member.php?u=77320 I'm on the fence about using TMO. The new community seems to be largely on FSO now. I don't think @nephros has an account. I agree a forum thread is the way to go.
• "O.K., if I join your Patchmanager team"? Yes! You were more terse the last time "I am only good at shell code!" so I incorrectly thought that you weren't "in". Nice panel of software, I've already used sfos-upgrade - so forgive me if "I must be new here"
• "What does @nephros think about this" Let's see:)

[Olf0]

@SfietKonstantin, because I do want to avoid migrating the development of Patchmanager for SailfishOS to a different location, the new "Patchmanager developers team" needs permissions to fully manage this repository, plus it would be advantageous to be able to create new repositories in https://github.com/sailfishos-patches/
As I volunteered for executing the organisational tasks within the fresh "Patchmanager developers team" (@b100dian and @nephros volunteered to perform the principal task: coding), it would be sufficient to grant me full administrative access. I believe we know each other for long enough (more than half a decade), that you might sufficiently trust me to maintain https://github.com/sailfishos-patches/ responsibly. While I do plan to perform some janitorial work, I will never delete anything (but likely archive some things in the long run, e.g. the old pre-SFOS2 patchset-repos sailfishos-patches-base and sailfishos-patches-advanced).
If you agree to grant me full administrative rights, I will also handle that responsibly (which implies "somewhat restrictively"), so you do not have to care about that. I.E. @b100dian and @nephros will get the rights they need to perform their work. All other new developers will have to start with MRs and only get merge rights, if they have proven to be careful and responsible. And I guess you know that I do not hesitate to retract any permissions if someone misbehaves.

The much worse alternative would be to migrate the development of Patchmanager for SailfishOS to a different location (likely still at GitHub, so we can start with a "one click fork" of this repository), but this would render numerous links pointing here invalid, break context and history (provided by the sister-repos in sailfishos-patches) etc.

[Ancelad]

Hello. Sorry for delay, I'm very busy on main job. I always agree with any improvements, but still don't know anything about PM4 development progress. Something is out of control at this moment... My nickname on TMO - Ancelad. If you will create new forum thread - I will join to discussion. I have some plans about transifex migration to GitHub, but still can't do it - as I said before I work hard on main job. чт, 16 сент. 2021 г., 00:32 Vlad G. ***@***.***>:

…

Hi @Olf0 <https://github.com/Olf0>, I'll try to answer the last part of your message for now: - "Do you have full control over this repository" I don't have full control, I can merge pull requests. I was planning to branch out patchmanager3.1 - had the same idea as you (plus, pm4 is taken:) - but I can't yet change the default branch. I consider this as a non blocker for the goal to have openrepos 3.1 version, can be handled later. - "What is your nickname at TMO"? https://talk.maemo.org/member.php?u=77320 I'm on the fence about using TMO. The new community seems to be largely on FSO now. I don't think @nephros <https://github.com/nephros> has an account. I agree a forum thread is the way to go. - "O.K., if I join your Patchmanager team"? Yes! You were more terse the last time "I am only good at shell code!" so I incorrectly thought that you weren't "in". Nice panel of software, I've already used sfos-upgrade - so forgive me if "I must be new here" - "What does @nephros <https://github.com/nephros> think about this" Let's see:) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#45 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVF55SPRS6YZ2FDARGGVNDUCDYFRANCNFSM4NWBMISQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[Olf0]

Hello @Ancelad,

really nice to receive a message from you. I hope you are well, besides being overly busy.

Fundamental message

Don't worry, nothing is happening in a hurry, we are glad if some of the old developers react at all.

Specific details

Andrey (Андрей Кожевников / CODeRUS) decided to stop developing for SailfishOS in his spare time, thus he ceased to maintain all his software (though he still is contracted by OMP and works on SFOS components, as far as I understand).

Consequences for Patchmanager

Vlad G. (b100dian / vlagged) had already started adapting Patchmanager 3.0 to SFOS 4.x (because changes in SFOS broke PM), now @nephros has also joined the new "Patchmanager developers team". I am trying to help them organisationally and am slowly preparing a new Openrepos page for PM.
My biggest organisational worry is, how to obtain administrative control over the translations at Transifex (that seems impossible without Andrey's support, but unfortunately he is not responding) and this source repository (Sfiet Konstantin is also not responding; staying here would be nice, but we can fork and move easily).

Patchmanager 4

Its development stalled since 2018-02-19: Currently there is only a single large commit atop the codebase of PM3 back then. To me it looks like a partial rewrite in order to get rid of old, ugly code.
Currently all efforts are aimed at maintaining PM3 and gaining administrative control over the extant infrastructure or moving to new infrastructure, which its needed for is development / maintenance.

Your patches

BTW, are you willing to test and update your patches for SFOS 4.x, when PM is running well on SFOS 4.x and you can spare a little time? AFAIU, you now have a SFOS device to test, again. And your patches have been essential (for me and many others).

Further action

I will write an email to Andrey at his gmail address this weekend, which is my effort to contact him (beyond "@ mentions" here and at FSO) and ask him how we may transfer control over infrastructure (esp. Transifex), plus a couple of minor things (license etc.).
Or do you already have administrative rights at Transifex for PM?