Release planning for Patchmanager 3.2.0

[Olf0]

"As discussed"^ᵀᴹ the "automatic 32 / 64 bit patch conversion" (PR #109) is going to be the principal feature for this release.

But somebody might have additional, minor things, he wants to have in this release.

While I intend to work on issue #17, I do not care in which release these minor string changes (which I still have to develop) are going to be applied. Hence this is nothing to really wait for (but also definitely nothing which would stop #109 to be the principal feature or make debugging it any harder).

The only reason, why I want to "stay in the loop" for this release, is that I intend to release some historic versions (for which I have finalised drafts) shortly (a few hours) before this one. Even though the tags are old, the drafts are freshly created, hence I am not sure how they will be sorted relative to the 3.1.x releases: I definitely do not want any of them to be displayed as "latest release" by GitHub (for more than a few hours) on the project front-page.
The intention for these releases is to backup all binaries at the Openrepos PM3.0 page with some context (Andreys brief change notes at Openrepos, their tag at GitHub and their tagging date).

[nephros]

I'm working on a couple of things but none are in a state to go into a 3.2.x release at the moment.

These include Issues #148 #114 #39 and PRs will come if they're ready (work can be seen in my fork).

Another thing probably worth tackling is #10, improving the update check.

[b100dian]

I merged #109 - I tried my best at testing all scenarios. However, we could leverage a 3.2.0 chum:testing only if that would bring us additional testing - and make some kind of announcement for testing on FSO. Thoughts?

[nephros]

Thanks!

I think as we for now "hide" it behind a config option, it's fine even if something breaks.

I do expect some fallout from people attributing all kinds of patch failures to either the 64bit "problem", or our solution - but that is still better than the guaranteed failure 64bit users are facing now.

[Olf0]

However, we could leverage a 3.2.0 chum:testing only if that would bring us additional testing - and make some kind of announcement for testing on FSO. Thoughts?

With an announcement this may work (for very few testers), but if you do not explicitly describe what to test and how, I would expect no sigificant feedback beyond "saw no errors". But is that worth the effort? You seem to have tested thoroughly with knowledge what / how to test, at most others will do the same on their SFOS installations.

And do you really expect regressions? IMO it is rather likely, that some of the new functionality is not working correctly.
If your expectations are the same, I suggest to "simply release as usual".

Still the new "32 / 64 bit"-functionality may be worth being briefly described in an extant thread at FSO. As different aspects of it were spread over a couple of commits, even I am curious to see a concise write-up of the whole new "32 / 64 bit"-functionality (means: I lost overview of all these changes).
And that description should also be appended (after the bullet list of changes) in the release note; well rather the other way around: in the release notes first, then copying them to FSO.

[b100dian]

And do you really expect regressions?

Actually there may be no regressions since the option is not by default turned on.

may be worth being briefly described in an extant thread at FSO

Yes, I think I should do that.

Something like:

You can now apply patches made only for 32-bit paths such as /usr/lib/qt5/qml (silica patches) on 64 bit devices (and the other way around) by enabling the new option "Fix patches made for 32-bit or 64-bit only".

[Olf0]

Well, ... "No" 😜
Seriously: Much too technical, most people will not be able to identify "silica patches" and noone can tell which paths a patch uses without dissecting it. It sure is fine for explaining what technically happens, but needs some introduction (issue assessment etc.).

And the option text should be fixed before releasing it, IMO: It does not "fix" anything broken, rather "convert" (on the fly).

I will continue to think about it in a couple of hours.

[b100dian]

Our users are smarter than theirs?

But sure, re-think the text field

[Olf0]

Our users are smarter than theirs?

Took a little time for me to comprehend, but "Yes, our subset of the SFOS-users (i.e., the PM-using ones) does outsmart the full set."
Perfect example in this context: https://forum.sailfishos.org/t/patchmanager-patches-in-koli-4-0-1/4925/162

But sure, re-think the text field

I will try to come up with something for both, bus as it has gotten really late, this will be tomorrow. [Did it right away.]

Actually for the text field, "Convert Patches from and to 32 bit and 64 bit" or "Convert Patches between 32 bit and 64 bit" is my spontaneous suggestion.

And for the intro:
With SailfishOS 4.1.0, Jolla rolled out their first 64 bit SailfishOS version, which is only available and mandatory on the Xperia 10 II. Patches will use the wrong paths for QML components, if they are not run on 32 bit / 64 bit SailfishOS they were written for. Hence Patchamnager 3.2.0 introduces an automatic conversion for Patches, which can be enabled by setting the new option "<option text>". [You might add your plans for the future: Enable it per default, or eliminate the option and always convert.] Note that other 32 bit / 64 bit specifics of a Patch cannot be automatically converted, hence running a 32 bit Patch on a 64 bit SailfishOS and vice versa may still fail, despite having this option enabled.
Because this feature of Patchmanager is new, reporting any issues with it here or at Github is crucial to perfect it, so please try it and provide feedback.

[b100dian]

Done https://github.com/sailfishos-patches/patchmanager/releases/tag/3.2.0

[nephros]

... and announced!

https://forum.sailfishos.org/t/announcing-patchmanager-3-2-0-now-with-64-bit-transmogrifier/9125

[Olf0]

@nephros, thank you for the excellent write-ups: The announcement proper and the issue description.

Unfortunately the latter contains a single digit, but very confusing typo:

And this is what 3.4.0 does now.

And this is what Patchmanager 3.2.0 does now.

... in my suggestion for fixing that typo and improving the whole sentence.

[nephros]

@nephros, thank you for the excellent write-ups: The announcement proper and the issue description.

Unfortunately the latter contains a single digit, but very confusing typo:

And this is what 3.4.0 does now.

And this is what Patchmanager 3.2.0 does now.

... in my suggestion for fixing that typo and improving the whole sentence.

Fixed thanks. My subconscious is too attached to SFOS 3.4 still it seems. I made that mistake three times (i.e. everytime)!

[Olf0]

BTW, "[You might add your plans for the future: Enable it per default, or eliminate the option and always convert.]", I really would appreciate discussing this: While for testing purposes an opt-in option is fine, I believe this must change some time soon (e.g., with the next release)!

• If the goal is to alleviate Patch authors from offering separate 32 and 64 bit versions, they must be able to rely on this feature being present.
• In general "options express the inability of the programmers to decide for sensible defaults".
  When I first read this, I thought of it as a harsh stance, but over the years I became convinced that this phrase bears much truth, especially in areas, where the average user does not have sufficient knowledge to meet an educated decision (e.g., file system parameters, other low-level system settings).

Ideas, opinions?