| 25 Aug 2020 |
 _hc | things like that seem to me to be all about addictive design: hooking the user so their eyeballs can be sold to the ads customers | 10:24:01 |
| _hc | just keeping them clicking and clicking on their device, don't let them think about what they are doing | 10:24:24 |
| _hc | any pause in the clicking is an opportunity for the user to break out of the addiction and lead their eyeballs away from the screen, where they no longer can be monetied | 10:25:17 |
| _hc | * any pause in the clicking is an opportunity for the user to break out of the addiction and lead their eyeballs away from the screen, where they no longer can be monetized | 10:25:25 |
 cdesai | There can be legitimate use cases too, I remember getting a duo notification once on stock and being able to join a video call instantly without having the app installed. It can be a good way to try some apps too. | 10:26:50 |
|  marzzzello joined the room. | 10:27:10 |
| marzzzello left the room. | 10:27:11 |
| cdesai | The instant apps had a lot more limited access than regular apps, e.g. via SELinux rules, so that'd be an additional benefit | 10:27:54 |
| _hc | sure, its nice to have apps install faster. Google puts a lot of effort into things like that align with their business model. | 11:12:55 |
| _hc | things would look different with a different business model | 11:13:13 |
| _hc | and compared to a theorical ideal free software device | 11:13:26 |
| _hc | I think most users would like to use the same apps forever, and have those evolve. E.g. I trust "Foo" for communications, and their magical app does email, matrix, etc. etc. | 11:14:18 |
| _hc | if all the new tricks were free software libraries, then the apps could just be different UXes on the same tech, and users could stick with Foo since Foo would be able to use the latest protocols, etc | 11:15:29 |
| _hc | Bubu: please don't self-merge things like s!787 which are both security sensitive and brittle, old code that is mission critical | 12:35:01 |
![@freenode_[gibot]:matrix.org](./avatar/%5Bgibot%5D) [gibot] | [server] !787: Some publish.py improvements - https://gitlab.com/fdroid/fdroidserver/merge_requests/787 | 12:35:03 |
 Bubu | _hc: you just approved it...? | 12:36:17 |
| Bubu | I interpreted this as "go ahead and merge it, if you feel like this is finished" | 12:37:33 |
| _hc | I was literally writing on it and finishing up when you clicked merge | 12:37:39 |
| _hc | I suppose the Approve is the same a merge, true | 12:38:03 |
| _hc | but I try to never leave a MR open if I think its ready to merge | 12:38:42 |
| _hc | but one approval is not always enough for some pieces, especially crazy old stuff | 12:39:13 |
| Bubu | In reply to @eighthave:matrix.org
but one approval is not always enough for some pieces, especially crazy old stuff yeah, though fdroidserver is unlikely to get any other reviewers from recent experience :-/ | 12:39:57 |
| _hc | true, sometimes it requires nagging people | 12:40:49 |
| _hc | publish is luckily pretty small and isolated and easily testable | 12:41:12 |
| _hc | or at least I hope that's the case | 12:41:34 |
| Bubu | _hc: so was there anything blocking this merge in your opinion? | 12:47:28 |
| Bubu | (but then you wouldn't have approved it I guess.) | 12:47:41 |
| * Bubu is confused | 12:47:45 |
| _hc | that merge request is fine. I'm just saying in general on fdroidserver, we should avoid self-merging, especially if it is on: old/crazy code, security-sensitive code, and/or things that are central to production | 12:49:16 |
| Bubu | I'm currently continuing breaking publish:main() apart somewhat more and writing tests for the resulting functions. | 12:51:26 |
