Necessary steps for maintaining PM

[Olf0]

This is a continuation of this discussion thread

Answering @b100dian's last response there:

As far as I understand the open points from the transition are: Transifex and license

... plus the code of the web-service for the web-catalog (https://coderus.openrepos.net/pm2 and sub-pages), which likely relies on the sailversion crawler (https://coderus.openrepos.net/whitesoft/sailversion ; its code is also needed for sfos-upgrade).

I tried to concisely document all the open points in my e-mail to Andrey.
You may trigger him per chat, that answering this mail would be really helpful for us to proceed.

P.S.:

I see you've evaluated GH Discussions a bit @olf. I'd like to move the developers/transition discussion there instead of PRs:)

Done.

[nephros]

... plus the code of the web-service for the web-catalog (https://coderus.openrepos.net/pm2 and sub-pages), which likely relies on the sailversion crawler (https://coderus.openrepos.net/whitesoft/sailversion ; its code is also needed for sfos-upgrade).

Do we view the web services as in-scope for this project?
I get they are an important part of the "user experience", but maintaining those is way different from maintaining an app.

[Olf0]

As @b100dian already stated: "Step by step"

1. Yes, they are definitely part of the Patchmanager3 infrastructure.
   • Without the web-catalog the user experience is much worse.
   • Without the web-catalog the patch maintainer's experience is much worse (having to build an RPM and publish it at Openrepos).
   • Without the web-catalog the overall experience is much worse, because there is no good way to handle a patch's dependency on sailfish-version for patches packaged as RPMs (been there, seen that).
     It is a bit tedious to fully explain this point, because it is a mix of technical, psychological and practical aspects.
2. • Without the source code for these web-services we are at zero. If nobody is willing to rewrite them from the scratch, they are gone. In this case the question is moot.
   • With the source code for these web-services, I hope they can easily be fixed and instanciated elsewhere (e.g. at patchmanager.github.io; we already have this page "reserved"). I expect them to consist of a couple of JavaScript lines, nothing more (hopefully).

This is why I try to obtain the code which runs
https://coderus.openrepos.net/pm2 and sub-pages,
plus https://coderus.openrepos.net/whitesoft/sailversion

[CODeRUS]

web catalog code available at: https://github.com/cODeRUS/django-test

[CODeRUS]

sailversion script is simply checking if https://releases.jolla.com/releases/{}/jolla/armv7hl/repodata/repomd.xml has 200 response, plus some manual adding of release date and name per version

[Olf0]

Thank you for the hint.
Now I see (after a little experimenting), that this could be re-written as a shell script, primarily using curl and date -d "@$revision" +'%d %b %Y'.

..., plus some manual adding of release date and name per version

Really manually?!?
It looks like you parse the <revision> tag as the date (which yields the dates I see, testing a few examples), but some subtleties are yet unclear to me, so Copy&Paste'ing your original script somewhere (e.g., here, simply in a message) would be very helpful (no matter in which language and how "ugly" it is).

[CODeRUS]

i have a file https://coderus.openrepos.net/codenames.txt with codenames i am filling manually

and script in python does following after 200 resonse:

  r = request.text
  tree = html.fromstring(r.encode('utf-8'))
  timestamp = tree.xpath('//repomd/revision/text()')[0]
  date = datetime.date.fromtimestamp(int(timestamp))
  format_date = date.strftime('%d %b %Y')

  names = open('/home/coderus/sailversion/codenames.txt', 'r').read()
  names_dict = dict(line.split(',') for line in names.splitlines())

  codename = names_dict[version_3]
  output = '{} - {} - {}'.format(version, codename, format_date)

[Olf0]

Thank you.

[b100dian]

@CODeRUS thanks for adding 4.2.0.19
Can you also provide a statement on the license of patchmanager3?

The thing with the django project is that, as a running service, it is harder to hand over - for example, there must be some deployment credentials and/or database to back up/keep running.

I think we can make PRs with new sfos versions, like 4.2.0.21 - as an easy first step.

[Olf0]

@CODeRUS thanks for adding 4.2.0.19

... plus publishing all the other updates since 2017 for "django-test".

I think we can make PRs with new sfos versions, like 4.2.0.21 - as an easy first step.

Done: CODeRUS/django-test#1

The thing with the django project is that, as a running service, it is harder to hand over - for example, there must be some deployment credentials and/or database to back up/keep running.

Plus we will have to evaluate, where to run this service:

• Ask Basil to keep on hosting it at Openrepos (which appears to be the easiest solution), simply moving it to the Patchmanager account there.
• Evaluate if some Github infrastructure allows for running this service?

---

Can you also provide a statement on the license of patchmanager3?

Long version, from my e-mail:

2.2 a written statement from you as Patchmanager(2/3/4)'s creator to choose an OSI-approved (FLOSS) license: https://opensource.org/licenses
For example, "Feel free to pick an OSI-approved license (https://opensource.org/licenses) for Patchmanager's source code." is sufficient for me / us.
You sure may also pick an OSI-approved license, if you have a strong preference; otherwise we will make an educated and sensible choice (my suggestion is LGPL-2.1-only).
Background: The spec file currently states "License: ToDo" and the word "license" does not seem to be used anywhere else at PM's source repository at Github.
But "no license" is formally and legally incompatible with any proper FLOSS license.

[b100dian]

@CODeRUS do you know if changing the default branch needs an update on transifex? I don't see any new strings - or how's the workflow, I don't see an equivalent 'push' (as it's with the pull.sh)

[CODeRUS]

did you setup new translation team on transifex?

[b100dian]

No - I assumed that you're using this type of integration (requires a branch specified) and I joined the existing team to see if any new strings are there to be translated.

To create a new team I would have to create my organization first (which btw makes you check that it's OSS). Then I would create a new patchmanager3 integration. Then I'd create a team and invite the existing translators (?). Is this what you're suggesting or am I missing something essential. Thanks!

[CODeRUS]

if you want to keep existing team you should check if it possible to set a maintainter for it to accept new languages and verify translations

[b100dian]

Yes, Project Maintainer can

• Approve/deny language requests (only for the project they maintain)
• Change project-level settings (only for the project they maintain)
  among other things.

See the tables from here and below for the actual rights.

(Note that I've only read docs, not actually tested this)

[Olf0]

@CODeRUS: Also at Transifex, keeping the existing infrastructure and teams alive is much easier: One does not have to build everything from the scratch and the translators can continue to work where they did before.
Thus it would be really nice, if you set Vlad as "project maintainer".

[b100dian]

Thanks, I now have access and I've set up the Github integration with the following yaml

filters:
  - filter_type: file
    # all supported i18n types: https://docs.transifex.com/formats
    file_format: QT
    source_language: en
    source_file: translations/settings-patchmanager.ts
    # path expression to translation files, must contain <lang> placeholder
    translation_files_expression: 'translations/settings-patchmanager-<lang>.ts'

I've made a manual test on my fork (and my transifex 'org') and it should open PRs like this b100dian#4 whenever the translations are 100% or when I manually tell it to.

I haven't seen yet: an update of the settings-patchanager.ts (a background service will ..?)

[b100dian]

Update: transifex picked up the changes to translations made by #66 - all languages show 11 (or 12) new strings to translate.
Unfortunately the DE translations from ts files were not picked up :-S
The GitHub integration unhelpfully shows "2 resources" were pulled but not which

[b100dian]

Aaand we have our first Swedish translation! 🎆 https://github.com/sailfishos-patches/patchmanager/pull/80/files

[CODeRUS]

hi, so, about license stuff. unfortunately I'm not a licence expert, i write my code under WTFPL, but original patchmanager code already have some licence, so you can stick to it

[b100dian]

Thanks,
@Olf0, @nephros I think this means that BSD-3-Clause license can be used as initially intended

[Olf0]

Please review & provide feedback here: https://openrepos.net/content/patchmanager/patchmanager

[Olf0]

Also - we should really release - or Jolla releases SailfishOS 4.3 faster than us:) I'd like to hear your thoughts on when to put that tag on (which generates a build).

Please wait, until we have the two page "ABC" and "XYZ" ready.

And do not worry: Jolla is not quick.

[Olf0]

And I'd order the "report patches for PM here" point first, and patch bugs after.

I did this on purpose, because in the past the were more issues with patches than with Patchmanager.
But people started to file issues with patches as comments at Patchmanager's Openrepos page. This is why Coderus pointed that old TMO thread, which has all topics intermingled: Issues with patches, issues with Patchmanager and patch developer questions.

Do you still want it to be reordered?

BTW, I do not think we should allow for comments at Openrepos, when we have FSO page "ABC", in order to keep communication channels focused.

For bugs which occur with patches from the Web Catalog, please file them at the FSO thread "XYZ".

Patch devs have the option of adding a "discussion link" as well as a link to sources in the patch metadata. So perhaps we shouldn't point at a specific thread XZY, but alert the users at these metadata links.

Oh, I did not know, because I have never seen that!
In the past it was a permanent issue that people did not know where to report issues with patches from the Web Catalog.
Do patch authors actually use that?
But it sure is worth mentioning: Can you provide a one liner, where that info is displayed, then I will utilise it for rephrasing that line with the pointer to FSO page "XYZ".

[nephros]

And I'd order the "report patches for PM here" point first, and patch bugs after.

I did this on purpose, because in the past the were more issues with patches than with Patchmanager. But people started to file issues with patches as comments at Patchmanager's Openrepos page. This is why Coderus pointed that old TMO thread, which has all topics intermingled: Issues with patches, issues with Patchmanager and patch developer questions.

Yeah, the recent FSO thread had that too, where people were talking about "Launcher Combined patch" at the same time as trying to figure out what wasn't working with PM proper, and some wondering whether patch was actually a weird tool of PM or SailfishOS.
But in the end, (some) people don't read docs, they don't follow them, they just like to complain and demand a fix now from whoever they think they can grab.

Do you still want it to be reordered?

Nah, I'm good :)

BTW, I do not think we should allow for comments at Openrepos, when we have FSO page "ABC", in order to keep communication channels focused.

I don't care particularly either way - but as a user I find it a bit rude (and a little suspicious) when someone has turned off commenting. As a publisher I like getting feedback - but I guess that can be done on FSO as well.
Also, you can't report or submit anything on GH without an account - a thing that bugs me greatly and has actually made me NOT contribute to projects I could have helped. So I left a comment with the information I had, and the dev could pick it up or ignore it, their call. But that's just me being uncomfortable with feeding Big Data.

Patch devs have the option of adding a "discussion link" as well as a link to sources in the patch metadata. So perhaps we shouldn't point at a specific thread XZY, but alert the users at these metadata links.

Oh, I did not know, because I have never seen that! In the past it was a permanent issue that people did not know where to report issues with patches from the Web Catalog. Do patch authors actually use that? But it sure is worth mentioning: Can you provide a one liner, where that info is displayed, then I will utilise it for rephrasing that line with the pointer to FSO page "XYZ".

It's the "discussion" and "sources" fields in patch.json:
https://github.com/sailfishos-patches/patchmanager/blob/update-documentation/doc/example_patch.json.md

and will show up as clickable things on the Patch Page in PM.

[Olf0]

BTW, I do not think we should allow for comments at Openrepos, when we have FSO page "ABC", in order to keep communication channels focused.

I don't care particularly either way - but as a user I find it a bit rude (and a little suspicious) when someone has turned off commenting.

Basically yes, but if there is a explicit pointer to a discussion page, I think that will and must do.
(See also your point for a reporting link for patches in the Web Catalog, where you take the opposite position. 😉)

The crucial point is: We cannot really share this account at Openrepos.
While I am pondering to share the password for that account via an encrypted channel (OpenPGP Mail or XMPP-OMEMO, anyone?), there is only a single email address for notifications of new comments.

As a publisher I like getting feedback - but I guess that can be done on FSO as well.

👍

Also, you can't report or submit anything on GH without an account - a thing that bugs me greatly and has actually made me NOT contribute to projects I could have helped. [...]

There is a "solution" for that, which mentaljam uses on his Openrepos page for the Storeman-Installer, but I do not like it (rsp. its technical requirements) at all.

Patch devs have the option of adding a "discussion link" as well as a link to sources in the patch metadata. So perhaps we shouldn't point at a specific thread XZY, but alert the users at these metadata links.

Oh, I did not know, because I have never seen that! In the past it was a permanent issue that people did not know where to report issues with patches from the Web Catalog. Do patch authors actually use that? But it sure is worth mentioning: Can you provide a one liner, where that info is displayed, then I will utilise it for rephrasing that line with the pointer to FSO page "XYZ".

It's the "discussion" and "sources" fields in patch.json: https://github.com/sailfishos-patches/patchmanager/blob/update-documentation/doc/example_patch.json.md

and will show up as clickable things on the Patch Page in PM.

Ah, these fields are optional, and most patch authors do not set them.
Supposedly this is why I never noticed that.

Nevertheless I added half a sentence to the first bullet point of "where to file bug reports".

[Olf0]

Plus these fields were not displayed, until @nephros fixed that couple of days ago.

[Olf0]

I think this discussion thread is worth being kept for a while.
I just "unpinned" it i.e., it is not displayed extra-prominently, any more) and will "lock" it (which makes no difference for maintainers).