Document commit workflow and branches #163

Olf0 · 2022-03-04T23:15:30Z

@mentaljam, looking at these branches, I wonder what your commit workflow was and what we may have to change when working as a team?

I see that the branches dev and master are even, so I assume you developed in dev and then pushed commits to master, correct?
This would now become (as master is "protected"): One branches out from ~~master~~ devel to, e.g., olf-patch-1, poses a PR which has to be reviewed and ultimately is merged back to ~~master~~ devel.
~~This scheme makes dev superfluous, AFAICS. If this is confirmed, I will delete it.~~
Edit: 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.

Then is looks as if you merged master into the release branches sfos3.2 for SFOS ≤ 3.2.0, sfos3.3 for SFOS ≥ 3.3.0 and sfos4.2 for SFOS ≥ 4.2.0, correct?
These are fetched by your OBS configuration and compiled there, right?
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.

This leaves the branches release_sfos3.2, release_latest and touring, 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.

The text was updated successfully, but these errors were encountered:

mentaljam · 2022-03-05T06:39:49Z

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.

poetaster · 2022-03-05T12:18:17Z

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 :)

poetaster · 2022-03-05T12:37:06Z

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?

poetaster · 2022-03-05T14:28:14Z

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.

poetaster · 2022-03-07T14:23:31Z

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:

point service branch at sfos3.3
disable all repositories < 3.? > 3.4.0.24
build for everything up to 3.4.0.24
point service branch at sfos4.2
disable all repositories < 4.x > 4.3.0.15
build for everything up to 4.3.0.15

But this all feels wrong.

Olf0 · 2022-03-07T14:46:30Z

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:

"*-sfos3.2" for SFOS 3.1.0 & 3.2.1 (Chum does not offer 3.2.0, but it would compile for that, too)
"*-sfos3.4" for SFOS 3.3.0, 3.4.0, 4.0.1 & 4.1.0.

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.

Olf0 · 2022-03-07T16:00:29Z

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:

Please do not use outdated versions. v0.2.11 is recent, see https://github.com/storeman-developers/harbour-storeman/tags
Please do not user master, use the release branches, see https://github.com/storeman-developers/harbour-storeman/wiki/Delta-between-release-branches-and-master

See mentaljam's _service configuration files (plural!) for reference https://build.sailfishos.org/project/show/home:mentaljam

poetaster · 2022-03-07T16:22:46Z

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.

poetaster · 2022-03-07T16:24:16Z

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.

poetaster · 2022-03-07T16:25:48Z

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.

poetaster · 2022-03-07T16:36:16Z

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.

Olf0 · 2022-03-07T16:37:26Z

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?

https://build.sailfishos.org/project/show/home:mentaljam
I.e., 5 packages in this project.
https://build.sailfishos.org/project/show/home:poetaster:storeman
I.e., 2 packages in this project!

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?

poetaster · 2022-03-07T16:52:34Z

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.

poetaster · 2022-03-07T17:02:43Z

@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.

poetaster · 2022-03-07T17:04:27Z

P.S. You put the fire under my butt by emphasizing the coming 4.4 release! Yes, that's a good excuse!

Olf0 · 2022-03-07T17:08:10Z

I'm faster than Jolla ;)

That is easy, even a tortoise is. 😜
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).

👍
I would appreciate, if you also replicate the fifth sub-repo *-testing ~~with the same targets as the sfos3.3 one: 3.3.0, 3.4.0, 4.0.1 & 4.1.0~~
I will push my pending PRs to the ~~dev~~ (now 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 · 2022-03-07T17:12:12Z

@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!

Olf0 · 2022-03-07T17:23:54Z

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.

poetaster · 2022-03-07T17:49:51Z

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!

poetaster · 2022-03-07T21:50:55Z

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 :)

Olf0 · 2022-03-08T01:07:48Z

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." 😉

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 ~~dev~~ (now 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.

Olf0 · 2022-03-08T02:09:32Z

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.

poetaster · 2022-03-08T08:27:28Z

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.

poetaster · 2022-03-08T09:25:40Z

As for all of: #163 (comment)

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!

Olf0 · 2022-03-08T17:03:24Z

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.

poetaster · 2022-03-08T17:37:46Z

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?

poetaster · 2022-03-08T20:40:37Z

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.

poetaster · 2022-03-08T21:02:17Z

As for how I prefer doing git flow, although I rarely get to this level of refinement

poetaster · 2022-03-09T08:36:04Z

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?

Olf0 · 2022-03-09T10:09:23Z

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.

poetaster · 2022-03-09T10:34:30Z

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.

poetaster · 2022-03-09T10:36:05Z

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.

Olf0 · 2022-03-09T11:29:55Z

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

Olf0 · 2022-03-09T12:57:11Z

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:

Why is the Storeman Installer so complicated to use?
BTW, this is also RPM / spec file work, in case you like that.
Furthermore the SailfishOS:Chum GUI application is also eagerly awaiting a solution for this: An easy to use installer app which obsoletes chumrpm.netlify.app (which constitutes an even more manual process than the current Storeman Installer).
The war and Russia's relations to the western world rsp. vice versa.
Not much we can do about that, unfortunately.
And basil does his best to keep OpenRepos up and running, AFAICS.

poetaster · 2022-03-09T14:58:54Z

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.

mentaljam · 2022-03-09T15:11:46Z

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...

poetaster · 2022-03-09T17:39:27Z

Ok, as I've mentioned elsewhere, could also be accomplished with a single unified diff.

poetaster · 2022-03-09T17:45:50Z

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.

Olf0 · 2022-03-09T20:00:53Z

@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.}

Olf0 · 2022-03-09T23:30:00Z

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.

poetaster · 2022-03-10T08:20:09Z

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.

poetaster · 2022-03-10T08:23:34Z

… 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.

mentaljam · 2022-03-10T10:19:16Z

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.

mentaljam · 2022-03-10T10:22:33Z

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

poetaster · 2022-03-10T10:40:18Z

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

poetaster · 2022-03-10T10:43:51Z

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.

mentaljam · 2022-03-10T11:16:35Z

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

poetaster · 2022-03-10T14:07:40Z

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.

Olf0 · 2022-03-10T19:33:10Z

@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.

Olf0 · 2022-03-11T00:45:47Z

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.

poetaster · 2022-03-11T22:17:26Z

c. No, the sfos3.3 version does "not work [on SFOS] < 3.3[.0]".

So, let's fix that and reduce the complexity of this by one branch.

Olf0 added the documentation Documentation, Wiki and related label Mar 4, 2022

Olf0 self-assigned this Mar 5, 2022

Olf0 closed this as completed Mar 9, 2022

Olf0 mentioned this issue Mar 9, 2022

Submitting Storeman to the SailfishOS:Chum testing repository sailfishos-chum/main#77

Closed

Olf0 mentioned this issue Mar 21, 2022

Documenting new infrastructure and migrating to it #266

Closed

Document commit workflow and branches #163

Document commit workflow and branches #163

Comments

Olf0 commented Mar 4, 2022 • edited Loading

mentaljam commented Mar 5, 2022 • edited Loading

poetaster commented Mar 5, 2022

poetaster commented Mar 5, 2022

poetaster commented Mar 5, 2022

poetaster commented Mar 7, 2022 • edited Loading

Olf0 commented Mar 7, 2022 • edited Loading

Olf0 commented Mar 7, 2022 • edited Loading

poetaster commented Mar 7, 2022

poetaster commented Mar 7, 2022

poetaster commented Mar 7, 2022

poetaster commented Mar 7, 2022

Olf0 commented Mar 7, 2022 • edited Loading

poetaster commented Mar 7, 2022

poetaster commented Mar 7, 2022

poetaster commented Mar 7, 2022

Olf0 commented Mar 7, 2022 • edited Loading

Olf0 commented Mar 7, 2022

Olf0 commented Mar 7, 2022 • edited Loading

poetaster commented Mar 7, 2022

poetaster commented Mar 7, 2022

Olf0 commented Mar 8, 2022 • edited Loading

Olf0 commented Mar 8, 2022 • edited Loading

poetaster commented Mar 8, 2022 • edited Loading

poetaster commented Mar 8, 2022

Olf0 commented Mar 8, 2022

poetaster commented Mar 8, 2022

poetaster commented Mar 8, 2022 • edited Loading

poetaster commented Mar 8, 2022

poetaster commented Mar 9, 2022

Olf0 commented Mar 9, 2022 • edited Loading

poetaster commented Mar 9, 2022

poetaster commented Mar 9, 2022

Olf0 commented Mar 9, 2022 • edited Loading

Olf0 commented Mar 9, 2022 • edited Loading

poetaster commented Mar 9, 2022

mentaljam commented Mar 9, 2022

poetaster commented Mar 9, 2022

poetaster commented Mar 9, 2022

Olf0 commented Mar 9, 2022 • edited Loading

Olf0 commented Mar 9, 2022 • edited Loading

poetaster commented Mar 10, 2022

poetaster commented Mar 10, 2022

mentaljam commented Mar 10, 2022 • edited by Olf0 Loading

mentaljam commented Mar 10, 2022

poetaster commented Mar 10, 2022

poetaster commented Mar 10, 2022

mentaljam commented Mar 10, 2022

poetaster commented Mar 10, 2022

Olf0 commented Mar 10, 2022 • edited Loading

Olf0 commented Mar 11, 2022 • edited Loading

poetaster commented Mar 11, 2022

Olf0 commented Mar 4, 2022 •

edited

Loading

mentaljam commented Mar 5, 2022 •

edited

Loading

poetaster commented Mar 7, 2022 •

edited

Loading

Olf0 commented Mar 7, 2022 •

edited

Loading

Olf0 commented Mar 7, 2022 •

edited

Loading

Olf0 commented Mar 7, 2022 •

edited

Loading

Olf0 commented Mar 7, 2022 •

edited

Loading

Olf0 commented Mar 7, 2022 •

edited

Loading

Olf0 commented Mar 8, 2022 •

edited

Loading

Olf0 commented Mar 8, 2022 •

edited

Loading

poetaster commented Mar 8, 2022 •

edited

Loading

poetaster commented Mar 8, 2022 •

edited

Loading

Olf0 commented Mar 9, 2022 •

edited

Loading

Olf0 commented Mar 9, 2022 •

edited

Loading

Olf0 commented Mar 9, 2022 •

edited

Loading

Olf0 commented Mar 9, 2022 •

edited

Loading

Olf0 commented Mar 9, 2022 •

edited

Loading

mentaljam commented Mar 10, 2022 •

edited by Olf0

Loading

Olf0 commented Mar 10, 2022 •

edited

Loading

Olf0 commented Mar 11, 2022 •

edited

Loading