search

sailfishos-chum / sailfishos-chum-gui

GUI application for utilising the SailfishOS:Chum community repository
https://openrepos.net/content/olf/sailfishoschum-gui-installer
MIT License
13 stars 16 forks source link

[Suggestion] Prepare to deal with `sailfishos/ssu` PR #16 #270

Closed nephros closed 1 month ago

nephros commented 2 months ago

DESCRIPTION

An unannounced and unreleased Sailfish OS version ("4.6") will change the way versions are handled in the ssu utility.

I imagine this may have an impact on how Chum GUI handles/must handle OBS repository information, hence this issue.

ADDITIONAL INFORMATION

Olf0 commented 2 months ago

See also https://github.com/sailfishos-chum/sailfishos-chum-gui-installer/issues/39, https://github.com/storeman-developers/harbour-storeman-installer/issues/308 and https://github.com/storeman-developers/harbour-storeman/issues/488.

Please use https://github.com/sailfishos-chum/sailfishos-chum-gui/issues/270 (i.e. this issue) as the main, tracking issue for this.

Olf0 commented 2 months ago
  1. Thank you for the heads up, @nephros.
  2. On first sight, sailfishos/ssu#16 looks like a backward compatible change to me. I may have missed something, but the wording of the PR title ("Add … variables"), its description ("Allows using …") and Keto's IRC chat message ("… can be used …") supports my impression (actually such wording would be hideous, if something is changed in a non-backward compatible way).
  3. I am a little more afraid about the depicted change for SailfishOS 5.0.0, but I may read too much into the wording "… 5.0 we will cut down the full version down to 3 segments". Maybe the full version string will still be available, retrievable and usable, so extant software does not need to be altered.
  4. If any of these changes turn out to break software, I must clearly state that I am so sick of it: Despite Sailors reiterating how "valuable" the community is for them, we are mostly still treated as beta testing monkeys and specifically they could not care less about the developer community. All the mostly unnecessary breaking changes in the past rendered so much software by community developers dysfunctional, resulting in significantly less working software, though most components of SailfishOS support backward compatibility very well (e.g. Qt / QML, the Linux kernel, Shell and shell utilities, C-/C++-libraries etc.). But breaking changes continue to be introduced by Jolla / Jollyboys, still the completely outdated, long unsupported Qt 5.6 stays forever (and they refuse to talk about it, which is another layer of \<I refrain to write that publicly>)! Furthermore this perpetual flow of breaking changes causes so much frustration among users ("software does not work after upgrade, and stays this way if unmaintained") and developers ("Sailors steal my spare time again and again for adapting to the breaking changes they create during their paid working hours"; "I cannot work on enhancing my software, because Sailors keep me busy with fixing things they break"). I addressed this many times, here the last time, the replies always have been either ignoring and denying the issue or belittling and down-talking it.
  5. Consequently I strongly believe, if any of these changes break backward compatibility, this is an excellent chance to confront Jolla with the consequences: No working SailfishOS:Chum-GUI app, no working SailfishOS:Chum-GUI-Installer and Storeman-Installer and no working Storeman self-update. We must leave it this way for at least a month after a GA (general availability) release (i.e. EA releases do not count, because too few users are affected). Maybe then Jolla finally realises that the Jolla Store has become a bad joke long ago (due to Jolla's self-imposed restrictions), that SailfishOS users do depend on OpenRepos and SailfishOS:Chum, and ultimately that community developers are a crucial part of the SailfishOS ecosystem, hence Jolla cannot do without them. Thus I am asking everybody to do nothing until things break and then take their due time to analyse the situation thoroughly, followed by designing, discussing with everyone involved, lastly implementing and testing an adaption to the breaking changes: I am sure this process takes a double-digit number of weeks, starting with the EA release date. I have to add that Jolla's breaking changes caused so much work and frustration for me over the years that I am neither willing or able (due to a lack of energy) to quickly adapt the software I am maintaining to their negligence, again and again.
Olf0 commented 1 month ago

See also issue #287.