Closed Olf0 closed 2 years ago
Hi!
1 Yes
2, 3 At you wish :)
4 Yes, these branches contains specific patches for older SFOS releases
5 Yes
6 Yes, please :)
7 Yes. Honestly, I thought I've already deleted release_sfos3.2
and release_latest
. The touring
branch is for https://openrepos.net/content/osetr/storeman-only-turing-phone which is abandoned. So It could be archived/deleted.
P.S. I may be wrong somewhere as I haven't work with the repository for a long time.
Ok, with responses from @mentaljam the way forward seems clear.
I'll take on copying the obs packages to push them to chum if someone isn't already on it :)
I'm not sure about using 'release' branches. I do have a case where, only on chum, the app is > 4, only and I use a branch for that. But generally, if an app works from 3 on up, I use master and release tags. Something like
<services>
<service name="tar_git">
<param name="url">https://github.com/storeman-developers/harbour-storeman.git</param>
<param name="branch">master</param>
<param name="revision">v0.2.8-2</param>
<param name="debian">N</param>
<param name="dumb">N</param>
</service>
</services>
Comments?
Once the packages have arrived in chum:testing, I would ask rinigus or piggz to make @Olf0 @mentaljam and whoever is in the group at that time to obtain the rights to manage the chum packages.
I've now copied @mentaljam s configs one to one and have builds on at https://build.sailfishos.org/project/show/home:poetaster:storeman (subprojects).
The problem is that @mentaljam's repositories are 'disabled' piece for piece as he does new releases, if I see that correctly. And so the old builds won't be included in mine. To recreate this is a bit tricky and or very laborious.
If I'm correct, we'd need to go back to the service file pointing at:
But this all feels wrong.
I've now copied @mentaljam's configs one to one and have builds on at https://build.sailfishos.org/project/show/home:poetaster:storeman (subprojects).
Actually two are currently missing:
The one without suffix is for SFOS ≥ 4.2.0.
The problem is that @mentaljam's repositories are 'disabled' piece for piece as he does new releases, if I see that correctly.
No, each sub-repo covers a range of SFOS release versions. This is not a temporal, but a spatial separation. The three aforementioned ranges combined cover all SFOS releases offered by SailfishOS:Chum.
Just recreate what he did: https://build.sailfishos.org/project/show/home:mentaljam
And so the old builds won't be included in mine.
So what? Old Storeman builds are history. If you manage to successfully compile the recent Storeman release version (0.2.11) for all SFOS releases, IMO that is sufficient as a starting point.
I'm not sure about using 'release' branches. I do have a case where, only on chum, the app is > 4, only and I use a branch for that. But generally, if an app works from 3 on up, I use master and release tags. Something like
<services> <service name="tar_git"> <param name="url">https://github.com/storeman-developers/harbour-storeman.git</param> <param name="branch">master</param> <param name="revision">v0.2.8-2</param> <param name="debian">N</param> <param name="dumb">N</param> </service> </services>
Comments?
Yes:
v0.2.11
is recent, see https://github.com/storeman-developers/harbour-storeman/tagsmaster
, use the release branches, see https://github.com/storeman-developers/harbour-storeman/wiki/Delta-between-release-branches-and-masterSee mentaljam's _service
configuration files (plural!) for reference https://build.sailfishos.org/project/show/home:mentaljam
No, each sub-repo covers a range of SFOS release versions. This is not a temporal, but a spatial separation. The three aforementioned ranges combined cover all SFOS releases offered by SailfishOS:Chum.
The current setup in @mentaljam's obs _service file with the current meta for that package only builds from 4.2 and up. Which means he MUST have changed the meta for which releases should be built in a step wise fashion. I'm assuming that by building from new branches with lest build targets, he's preserving the older repositories. I don't like it, but it's doable. I've reproduced this current state.
I've sent him a PM to clarify.
I'll ask rinigus to clarify how, or if we can, do this in chum. It's not how chum is set up.
So what? Old Storeman builds are history. If you manage to successfully compile the recent Storeman release version (0.2.11) for all SFOS releases, IMO that is sufficient as a starting point.
The 'what' is that without a build in obs people will not be able to install because the installer adds an SFOS release specific repository url.
See mentaljam's
_service
configuration files (plural!) for reference https://build.sailfishos.org/project/show/home:mentaljam
This is already done. It precludes repositories for anything older than 4.2. Which means that storeman is not installable from my replication of the current @mentaljam settings. But I've alread asked him to clarify how he did this.
This is not a temporal, but a spatial separation.
I think I see what you mean. He's maintained different packages for each release. I'll replicate those, too.
No, each sub-repo covers a range of SFOS release versions. This is not a temporal, but a spatial separation. The three aforementioned ranges combined cover all SFOS releases offered by SailfishOS:Chum.
The current setup in @mentaljam's obs _service file with the current meta for that package only builds from 4.2 and up.
No, there are three _service
files:
Which means he MUST have changed the meta for which releases should be built in a step wise fashion.
No, as it is quite obvious and I documented it!
I'm assuming that by building from new branches with lest build targets, he's preserving the older repositories. I don't like it, but it's doable. I've reproduced this current state.
No, you did not. Do these really look the same to you?
I've sent him a PM to clarify.
Please do not bug him, he really lacks the time. Just read thoroughly, what I documented at https://github.com/storeman-developers/harbour-storeman/wiki/Delta-between-release-branches-and-master
I'll ask rinigus to clarify how, or if we can, do this in chum. It's not how chum is set up.
Please don't. It is all quite obvious and understandable, if you would slow your speed a bit. Yes, we can use the same setup at chum, as in mentaljams repo.
P.S.: Sorry to state that clearly, your flurry of activities makes my dizzy. Why this haste?
P.S.: Sorry to state that clearly, your flurry of activities makes my dizzy. Why this haste?
I'm faster than Jolla ;) Kidding. I just find it so aesthetically dissatisfying that I chose to think it was torture. But in reality, it's the lack of time that drives my haste. It's why I questioned if I was appropriate for this project.
In any case, I've now replicated his structures with the addition of 4.3.0.15 (and also the addition of build excludes where they belong).
And, I believe my PM to @mentaljam failed, and all is clear with rinigus.
@Olf0 I've added you as maintainer of: https://build.sailfishos.org/project/show/home:poetaster:storeman
When and if you are satisfied that they are correctly configured, you can promote them to chum directly, or delegate to me if you wish.
P.S. You put the fire under my butt by emphasizing the coming 4.4 release! Yes, that's a good excuse!
I'm faster than Jolla ;)
That is easy, even a tortoise is. :stuck_out_tongue_winking_eye: But in my perception you tend to overtake yourself regularly, at least today.
I just find it so aesthetically dissatisfying that I chose to think it was torture.
No, you were contemplating and complaining about the tedious and consecutive manual changes to the _service
file, which you imagined.
But in reality, it's the lack of time that drives my haste.
Then, please, take a break and do what is more urgent for you. If that is for a few days, that is fine for me: This is not a day job!
In any case, I've now replicated his structures with the addition of 4.3.0.15 (and also the addition of build excludes where they belong).
:+1:
I would appreciate, if you also replicate the fifth sub-repo *-testing
with the same targets as the
I will push my pending PRs to the sfos3.3
one: 3.3.0, 3.4.0, 4.0.1 & 4.1.0 (now dev
devel
) branch, which feeds that, first.
Though I doubt, that I will get around to still make that happen today (too much tedious typing here).
@Olf0 I've added you as maintainer of: https://build.sailfishos.org/project/show/home:poetaster:storeman
Thank you.
When and if you are satisfied that they are correctly configured, you can promote them to chum directly, or delegate to me if you wish.
The configuration per _service
files looks fine now. Thanks!
P.S. You put the fire under my butt by emphasizing the coming 4.4 release!
Ah, where? And when? Nowhere & never! It is not even in EA stage yet (just cBeta) and I could not care less, because my production phone is runs with SFOS 3.2.1 and my testing one with 4.0.1.
Yes, that's a good excuse!
For making this an stressful afternoon for both of us? Plus reaching out to mentaljam and rinigus to involve them too (and unnecessarily). No, not seriously.
For making this an stressful afternoon for both of us? Plus reaching out to mentaljam and rinigus to involve them too (and unnecessarily). No, not seriously.
I have a 9 year old child. I spent time on a trampoline today. But I'll simply slow down anyway. I produce to much useless text at the moment. Thanks for your patience!
No, you were contemplating about the tedious and consecutive manual changes to the
_service
file, which you imagined.
Actually, I was using meld to compare the successive releases, 3.2, 3.3 and 4.2 and thought, 'this can be simplified to everyone's benefit'. Personally, I'd punt 'sharing' (introduced in 4.2) and reduce this all to one repo and testing. But I'd have to do more testing first. Natch! That would get us from 5 down to 3. And allow us to use master plus release tags/releases instead of these branches that have barely a difference.
The workflow is much clearer then. At least from my sometimes addled perspective :)
Actually, I was using meld to compare the successive releases, 3.2, 3.3 and 4.2 and thought, 'this can be simplified to everyone's benefit'.
I do not comprehend what you were intending to research by doing that WRT the git-repo structure and workflow.
Personally, I'd punt 'sharing' (introduced in 4.2)
No, the sharing mechanism was completely overhauled and fundamentally altered by Jolla in SFOS 4.2, hence Storeman's sharing code was changed significantly (was becoming much simpler). "Use the force, read the source." :wink:
and reduce this all to one repo and testing. But I'd have to do more testing first. Natch! That would get us from 5 down to 3. And allow us to use master plus release tags/releases instead of these branches that have barely a difference.
The workflow is much clearer then. At least from my sometimes addled perspective :)
This is one type of a classic git workflow with a common master branch and various release branches. It utilises the fact, that commits are temporally ordered diffs: One has the release specific bits directly committed to the release branches and feeds everything common from a central branch (master
for Storeman); additionally we have a staging branch (now dev
devel
), which feeds into master
. IMO the is no reason to divert from this tried and trusted scheme. Especially not now, because all commit activities are still on the hold, until we have SailfishOS:Chum up and running with what is already there and double-checked that everything is working as intended.
I finalised the descriptions and package metadata (plus one package name) to have everything ready to be submitted to SailfishOS:Chum testing. I also had to introduce fixed tags rsp. commits, see SailfishOS:Chum Maintainer.md. We can revert that (I would actually prefer that) in your OBS repo after being in SailfishOS:Chum testing.
If you have sufficiently time tomorrow and still the strong urge to push forward, then I would appreciate, if you contact @rinigus, sort out the process in detail (the general process is described in the SailfishOS:Chum developer's guide) to submit OBS home:poetaster:storeman to SailfishOS:Chum testing and execute it. Storeman's special OBS repo structure may pose a hurdle, but IMO this should be feasible: Please discuss and evaluate this with @rinigus, if you have the time. Do not hesitate to involve me briefly (per @mention or phone); I have to work but can make a break at almost any time. Also do not hesitate to do nothing at all, that is absolutely fine. Speed in not at all paramount, but diligence definitely is: Anything which must be reverted or redone will cost manifold more time than getting it right in the first place.
Mind that the technical name always shall be harbour-storeman
, not just storeman
(as you used it as your subproject name). Probably it makes sense to create a subproject sailfishos:chum:testing:harbour-storeman
and to submit the individual packages to it as they are. BTW, all fields of the "Submit"-form except for the target repo can be left empty and default to the extant values, then. The header fields of the new sub-project have to be manually copied from the existing ones, IIRC.
Please name yourself, mentaljam and me as maintainers.
Thank you.
No, the "share" mechanism was completely overhauled and fundamentally altered by Jolla in SFOS 4.2, hence Storeman's sharing code was changed significantly (was becoming much simpler). "Use the force, read the source." wink
That is what I did. I, personally, would remove all the differences between the releases because they are of little utility. They do however come at the cost of maintaining multiple branches. Which means implementing fixes if, for instance, you find a security issue on one branch and need to apply a fix to multiple branches and rebuilding not one but three packages on obs.
But it's not my call. Parsimony, aka KISS, is what motivates me, but also having experience managing diverging branches on other projects.
As for all of: https://github.com/storeman-developers/harbour-storeman/issues/163#issuecomment-1061332990
I will get on this now. For the course of the day I won't be able to get back to it (child care, corona, etc.) but it will take some time for @rinigus to look it over.
Great work! Thanks!
They do however come at the cost of maintaining multiple branches.
From my experience it is rather Jolla regularly inducing such costs by incompatibly altering APIs. This even may be such simple things as the filesystem layout; e.g., where the SD card is mounted has been changed two times since SailfishOS' inception about 10 years ago (i.e., three different locations).
Which means implementing fixes if, for instance, you find a security issue on one branch
A security issue on one specific branch only needs to be fixed in this branch. An unlikely scenario though, as such a security issue would have to be located in one of the differences between the branches, which are minimal.
For security issues common to all branches …
and need to apply a fix to multiple branches
… this is extremely easy via git and …
and rebuilding not one but three packages on obs.
… OBS does that even without touching it (by detecting altered source files).
But it's not my call. Parsimony, aka KISS, is what motivates me, but also having experience managing diverging branches on other projects.
Oh, I fully agree on this, although technical simplicity is often a matter of perspective. But technical means shall never be used just because they exist ("because we can") and the release branches should only diverge to the extent absolutely necessary to provide the same functionality across all supported SailfishOS releases.
Ditching functionality for the "KISS" principle's sake is not an option IMO.
A security issue on one specific branch only needs to be fixed in this branch. An unlikely scenario though, as such a security issue would have to be located in one of the differences between the branches, which are minimal.
This is false since the C++ on all branches is the same. So a fix to one is a fix to all. It can be automated, but I don't trust automatons.
And whether or not it is easy, in security, as you know, every additional step, copy, etc., increases the error rate.
In the end, I don't really understand the use case for sharing in storeman, but it's probably a case of being under socialized in some sense. Removing the sharing (which depends on > 4 sfos) get's us one repo. But, you make the call. If we can get it down to 2 branches in chum, that'd be ok by me.
I also have some > 4 software. It benefits from the new WebView component as of SFOS > 4 and is software that would not be possible in older versions. So, it's not all bad when change comes :)
I DO think we can agree that the sfos3.2 branch is superfluous?
Ok, I saw this coming, but didn't want to be even more annoying than I already am:
rinigus> poetaster: can't you somehow organize it in a way where single master is pulled and options enabled/disabled depending on SFOS version?
<rinigus> right now it is a pain to accept and start enabling/disabling all the sfos/arch combinations
The simple solution is to remove the > 4 sharing QML, carefully review any other changes and move to one release branch.
The tricky version is conditionals in the spec which switch between QML files using old and new SFOS sharing methods.
EDIT: I just tried the sharing (from the version compiled with your patches) and it's not even a complete implementation. In my case, I can only share via email. That might as well be a copy url operation. I would much prefer that but take some time to look at, please.
It is, it seems, also being used in the CommentDelegate, not just the AppInformation page. But it boils down to the same thing.
I'm going to re-implement this without '4isms' and see if I can get us down to a master branch.
As for how I prefer doing git flow, although I rarely get to this level of refinement
I'm going to re-implement this without '4isms' and see if I can get us down to a master branch.
Ah, the sfos3.3 branch works fine on sfos 4.3.0.15. Hmmm. Perhaps we could start with just releasing that branch on Chum with all builds > 3.1 enabled for the initial test phase?
I'm going to re-implement this without '4isms' and see if I can get us down to a master branch.
Ah, the sfos3.3 branch works fine on sfos 4.3.0.15.
Sure it does, except for the "sharing" functionality. So do the master and the devel branches, too.
Hmmm. Perhaps we could start with just releasing that branch on Chum with all builds > 3.1 enabled for the initial test phase?
Gimme a little time (in days!), first I want to address Rinigus' "right now it is a pain to accept and start enabling/disabling all the sfos/arch combinations" as not really comprehensible. For this I will start a new thread and \@mention him and you there, because this one has become convoluted and deviated far off the original topic.
I DO think we can agree that the sfos3.2 branch is superfluous?
Personally this is my main interest (to keep it alive), because my "production" phone runs SFOS 3.2.1, as this is the latest release which does not provide some sort of a real bummer for me (only AAC playback is broken, so most internet radio stations are mute). I gave up eagerly awaiting the next release, but tested all of them on my testing phone. Jolla's software quality has been deteriorating a lot compared to SFOS 2.1.x up to 3.2.1 (that covers 3,5 years) in the past 2 years. Quality assurance was always almost non-existent, but the coding and assembling processes seem to have gone downhill quickly.
If I find some time tonight I'm going to try to use the power of the spec file. getting the sfos4.2 branch WITH sharing compatible is a question of switching 2 files, maybe 3. That can be done with the spec file. I don't recall if:
%if "%{sailfishos_version}" <
works.
Gimme a little time (in days!), first I want to address Rinigus' "right now it is a pain to accept and start enabling/disabling all the sfos/arch combinations" as not really comprehensible.
The settings, if i remember correctly are not copied directly. I think in this case they would have to do it by hand.
Gimme a little time (in days!), first I want to address Rinigus' "right now it is a pain to accept and start enabling/disabling all the sfos/arch combinations" as not really comprehensible.
The settings, if i remember correctly are not copied directly. I think in this case they would have to do it by hand.
Yes, Ctrl-c
& Ctrl-v
are your friends, see e.g., https://build.sailfishos.org/package/meta/home:poetaster:storeman/harbour-storeman-sfos3.2
At least I have finished the original task "Document commit workflow and branches" by releasing the first proper version of the Wiki page "Git commit workflow".
If I find some time tonight I'm going to try to use the power of the spec file. getting the sfos4.2 branch WITH sharing compatible is a question of switching 2 files, maybe 3. That can be done with the spec file. I don't recall if:
%if "%{sailfishos_version}"
works.
As this whole endeavour ought to be fun for you, go ahead if you like to. IMO the Git workflow and OBS structure is fine the way mentaljam designed it and it is tried & tested. You may wait though, if I can convince rinigus that this is no big deal. If I fail, this really becomes a task, which should be addressed sooner or later, even tough we can also use a (your) "private" SailfishOS-OBS repo (as mentaljam did) for a while.
Basically Storeman is working fine, only a few, minor janitorial tasks here at GitHub caught my eye.
The only real issues of the Storeman / OpenRepos ecosystem currently are:
Yes,
Ctrl-c
&Ctrl-v
are your friends, see e.g., https://build.sailfishos.org/package/meta/home:poetaster:storeman/harbour-storeman-sfos3.2
Reducing 4.2 and 3.3 to one branch, where source directory is 3.3 branch, and target directory 4.2 branch:
Step 1.
cp qml/components/CommentDelegate.qml ../harbour-storeman/qml/components/CommentDelegate3.qml
cp qml/components/PackageInformation.qml ../harbour-storeman/qml/components/PackageInformation3.qml
cp qml/pages/CommentsPage.qml ../harbour-storeman/qml/pages/CommentsPage3.qml
Step 2. In the spec file:
# >> install post
%if "%{sailfishos_version}" < "40000"
cp %{buildroot}%{_datadir}/%{name}/qml/components/CommentDelegate3.qml \
%{buildroot}%{_datadir}/%{name}/qml/components/CommentDelegate.qml
cp %{buildroot}%{_datadir}/%{name}/qml/components/PackageInformation3.qml \
%{buildroot}%{_datadir}/%{name}/qml/components/PackageInformation.qml
cp %{buildroot}%{_datadir}/%{name}/qml/pages/CommentsPage3.qml \
%{buildroot}%{_datadir}/%{name}/qml/pages/CommentsPage.qml
%endif
# << install post
And, for the record, I'm a vim user. I use yank and not ctrl this or that. that's for emacs users. in emacs I use evil. so, it's still yank.
Reducing 4.2 and 3.3 to one branch, where source directory is 3.3 branch, and target directory 4.2 branch:
Sorry, I don’t like this approach, because it mixes code for different SFOS versions in one branch. Furthermore it works for QML whereas we still need branches for the C++ part. Also all RPMs become “cluttered” with additional files which not necessary would be used.
But it’s only mine opinion...
Ok, as I've mentioned elsewhere, could also be accomplished with a single unified diff.
I went throught the difference in the c++. The 3.2 branch is not needed. All of the the c++, on initial inspection, not testing, will work.
Let me know if I should mock up a version with a unified diff.
@mentaljam, thank you for your contribution and advice. I highly value it, because you designed, implemented and used Storeman's git- and OBS-repo organisation and workflows.
To me these established structures and processes make a lot of sense, because they are simple and straightforward. This is why I documented them (in minimally altered form) at Storeman's Wiki-page "Git commit workflow" (note that the GitHub-action build-runner for the devel
branch is something I still have to establish).
Reducing 4.2 and 3.3 to one branch, where source directory is 3.3 branch, and target directory 4.2 branch:
Sorry, I don’t like this approach, because it mixes code for different SFOS versions in one branch. Furthermore it works for QML whereas we still need branches for the C++ part. Also all RPMs become “cluttered” with additional files which not necessary would be used.
This is a thought I also had. Additionally, trying to minimise the number of git branches in use complicates the spec file a lot, which makes it harder to maintain, prone to introducing errors and poses an additional hurdle for new contributors. I also still fail to understand what the reduction of branches really achieves (besides having less branches), because the commit processes would become more complicated than they currently are, the clear staging scheme with build checks for each stage would be gone etc.
As long as I do not understand the requirement which drives this, I am reluctant to pursue this. This appears to me as a "if it ain't broke, don't try to fix it" case.
Furthermore I assume it to be elegant to let the Storeman Installer download and install Storeman from the SailfishOS:Chum repository (because then one could alternatively use the SailfishOS:Chum GUI application for this), but not a requirement (or even a necessity); if the Storeman Installer continues to download and install Storeman from a "private" OBS-repository, that is fine, too.
The awkward, half-manual bootstrapping process to have Storeman initially installed without resorting to the CLI (or a web-browser, a file-manager and SailfishOS' Settings app) is currently my main concern, which is exacerbated by the fact that the SailfishOS:Chum GUI application is affected by exactly the same issue as Storeman (despite having a slightly different workaround, which is IMO not any better), and a solution will be applicable to both (i.e., one could easily derive a "SailfishOS:Chum GUI app Installer" from the Storeman Installer) .
P.S.:
And, for the record, I'm a vim user. I use yank and not ctrl this or that. that's for emacs users. in emacs I use evil. so, it's still yank.
… on web-pages? Really?
Oh yeah, with EMACS one can do everything: Mailing, surfing, swimming, cycling etc. I tend to forget that, because vi
/ vim
has been my primary choice for editing texts locally in the last three decades and with it one can only do one thing: editing text files.
BTW,
EDIT: I just tried the sharing (from the version compiled with your patches) and it's not even a complete implementation. In my case, I can only share via email. That might as well be a copy url operation. I would much prefer that but take some time to look at, please.
This is Jolla's new sharing mechanism. As always it came unannounced and might be changed at any time; but do not worry, that very likely will be "soon™" (i.e., by Jolla's standards).
The code in Storeman is fine AFAICS, I assume only a single "sharing sink" has registered itself at the new sharing mechanism on your device: Jolla's email application.
It is just a few lines of code to implement a "sharing sink" for the new sharing mechanism, so you can easily create more of them, if you want more.
Additionally, trying to minimise the number of git branches in use complicates the spec file a lot,
This is not the case. It could be 3 lines in the spec + a unified diff
diff -bur harbour-storeman/qml/components/CommentDelegate.qml harbour-storeman-master/qml/components/CommentDelegate.qml
--- harbour-storeman/qml/components/CommentDelegate.qml 2022-03-10 09:06:57.928116080 +0100
+++ harbour-storeman-master/qml/components/CommentDelegate.qml 2022-03-07 11:54:30.150443399 +0100
@@ -70,9 +70,10 @@
}
MenuItem {
- //% "Share link"
text: qsTrId("orn-share-link")
- onClicked: shareAction.shareLink("https://openrepos.net/comment/%1#comment-%1".arg(model.commentId))
+ onClicked: pageStack.push(Qt.resolvedUrl("../pages/SharePage.qml"), {
+ link: "https://openrepos.net/comment/%1#comment-%1".arg(model.commentId),
+ })
}
}
Only in harbour-storeman/qml/components: PackageInformation3.qml
diff -bur harbour-storeman/qml/components/PackageInformation.qml harbour-storeman-master/qml/components/PackageInformation.qml
--- harbour-storeman/qml/components/PackageInformation.qml 2022-03-10 09:06:57.928116080 +0100
+++ harbour-storeman-master/qml/components/PackageInformation.qml 2022-03-07 11:54:30.151443396 +0100
@@ -22,11 +22,10 @@
}
icon.source: "image://theme/icon-m-share?" +
(pressed ? Theme.highlightColor : Theme.primaryColor)
- onClicked: shareAction.shareLink("https://openrepos.net/node/" + app.appId, app.title)
-
- ShareLinkAction {
- id: shareAction
- }
+ onClicked: pageStack.push(Qt.resolvedUrl("../pages/SharePage.qml"), {
+ link: "https://openrepos.net/node/" + app.appId,
+ linkTitle: app.title,
+ })
}
IconButton {
Only in harbour-storeman/qml/components: ShareLinkAction.qml
Only in harbour-storeman/qml/pages: CommentsPage3.qml
diff -bur harbour-storeman/qml/pages/CommentsPage.qml harbour-storeman-master/qml/pages/CommentsPage.qml
--- harbour-storeman/qml/pages/CommentsPage.qml 2022-03-10 09:06:57.928116080 +0100
+++ harbour-storeman-master/qml/pages/CommentsPage.qml 2022-03-07 11:54:30.152443392 +0100
@@ -64,10 +64,6 @@
running: true
}
- ShareLinkAction {
- id: shareAction
- }
-
SilicaFlickable {
anchors.fill: parent
Basically.
Creating a branch that reduces the maintenance for the chum maintainers to basically zero is not only a laudable but even important goal. We have other work to do. I for one am working on numerous other apps and would like, for both storeman and chum-gui to finally work on the PackageKit issues.
As far as the installer is concerned, I tried all of olf's patches and it looks fine to me.
… on web-pages? Really?
Yes. I use vim bindings almost everywhere. All IDEs, window manager, FF. Obviously not everywhere. But I'm not really capable o using, for instance, Open Office.
The 3.2 branch is not needed
The master
branch contains C++17 code which fails to compile with GCC of the 3.2 target. And there are no guarantees that the next SFOS release will not break the compilation.
Also dependencies could be changed between versions. Of course we can put all the logic into the spec file. But, as I think, it's the path to complication. With branches we can keep the code clean for every supported bunch of SFOS versions. And if we decide to abandon some of it (3.2 for example) we can just drop the branch without patching (cleaning) the code.
OBS is not the only place for building packages. A person may want to build a package themself. Git branches seems to me the most universal and the most simple solution
The 3.2 branch is not needed
The
master
branch contains C++17 code which fails to compile with GCC of the 3.2 target. And there are no garantes that the next SFOS release would not break the compilation.
Do we need the 3.2 target? What is it's purpose? Does the sfos3.3 version not work < 3.3? Can the current master branch be built against a 3.4 target which will also work with 3.1 - 3.3?
Also dependencies could be changed between versions. Of course we can put all the logic into the spec file. But, as I think, it's the path to complication. With branches we can keep the code clean for every supported bunch of SFOS versions. And if we decide to abandon some of it (3.2 for example) we can just drop the branch without patching (cleaning) the code.
I agree with this. And of course don't want to manage too many (mileage varies) patches. But I don't like the idea of breaking the source of packes in CHUM proper every time a new release comes along and one of the two maintainers don't have time, are on vacation or ill and we wind up with conflicting builds. That's fragile.
I would go along with the status quo if WE maintain the obs backend. I'm even willing to post my availability to a shared calendar to ensure that someone is available. But pushing it to chum creates work for others that I don't wish to be responsible for. I'm fine doing the work 'your way' as evidenced by the fact that I simply implemented your scheme in the first place. Then let us simply manage it outside of chum.
The installer can remain in chum with no issues, though we should put chum meta data in the spec file so that people see instructions in the chum gui.l
OBS is not the only place for building packages. A person may want to build a package themself. Git branches seems to me the most universal and the most simple solution
OBS is not the issue. The issue is the chum subsection which has a specific purpose and certain expectations. I don't like all of them but I accept them.
Can the current master branch be built against a 3.4 target which will also work with 3.1 - 3.3?
I'm not sure because of linked libraries
Can the current master branch be built against a 3.4 target which will also work with 3.1 - 3.3?
I'm not sure because of linked libraries
Ok, I'll take a crack at making a 3.x branch with 3.4 targets and see if I can find any volunteers to test.
@poetaster, please stop asking things in circles, again and again, when you already have proper answers!
\<poetaster> I DO think we can agree that the sfos3.2 branch is superfluous?
\<olf> Personally this is my main interest (to keep it alive), because my "production" phone runs SFOS 3.2.1,
\<poetaster> The 3.2 branch is not needed
\<mentaljam> The
master
branch contains C++17 code which fails to compile with GCC of the 3.2 target. And there are no guarantees that the next SFOS release will not break the compilation.\<poetaster> Do we need the 3.2 target? What is it's purpose? Does the sfos3.3 version not work < 3.3? Can the current master branch be built against a 3.4 target which will also work with 3.1 - 3.3?
a. Devices with SFOS < 3.3.0 (e.g., my "production" phone) need it.
b. Its purpose is to satisfy point a.
c. No, the sfos3.3 version does "not work [on SFOS] < 3.3[.0]".
d. No, see c., plus @mentaljam's comments [1] and [2].
P.S.:
I produce too much useless text at the moment. Thanks for your patience!
Frankly said, you still do, and this is really stressing my patience.
Sorry @poetaster, this escaped my attention in this convoluted thread:
I […] would like, for both storeman and chum-gui to finally work on the PackageKit issues.
Yes, please & thank you for offering this.
As far as the installer is concerned, I tried all of olf's patches and it looks fine to me.
I will start merging stuff, when I have the GH-actions build runner up: Hopefully this weekend. Side note: I want to try them with commits, of which I know that they are O.K.
@mentaljam, looking at these branches, I wonder what your commit workflow was and what we may have to change when working as a team?
dev
andmaster
are even, so I assume you developed indev
and then pushed commits tomaster
, correct?master
is "protected"): One branches out frommasterdevel to, e.g.,olf-patch-1
, poses a PR which has to be reviewed and ultimately is merged back tomasterdevel.This scheme makesEdit: I came to the conclusion that mentaljam's git flow is reasonable, especially when instrumented with automatic builds at every stage. Hence I documented his workflow at Storeman-Wiki: Git-commit-workflow.dev
superfluous, AFAICS. If this is confirmed, I will delete it.master
into the release branchessfos3.2
for SFOS ≤ 3.2.0,sfos3.3
for SFOS ≥ 3.3.0 andsfos4.2
for SFOS ≥ 4.2.0, correct?So I assume somebody should copy your OBS configuration, so you do not need to handle this any longer, right? I suggest to then submit this to SailfishOS:Chum:testing and lastly to SailfishOS:Chum, so we can adapt the Storeman Installer to let it grab the binaries at a single, canonical location.
release_sfos3.2
,release_latest
andtouring
, which appear to be the former release branches (before OBS), right? If they are indeed outdated branches, I will switch them to "read only" by a branch protect rule.@mentaljam, I posed all these question, that you can answer them by {Yes|No}, e.g., "3: Yes". But please add explanations where you think they are necessary.
@poetaster & @pherjung, any comments, ideas, contradictions etc.?
Everybody, please wait with committing to any of these branches until we have this sorted out and documented. You sure may work in your own, forked repository and pose pull requests, meanwhile.
If I have all answers, I will document them in the wiki, set the branch protection rules accordingly, and then we can start to commit to extant branches.