[2026-10-05T00:41:10Z] Vova: the package ownership model is kinda fucked up in kiss [2026-10-05T00:41:48Z] whoever pushes to the version file becomes a maintainer of that package [2026-10-05T00:43:11Z] which is why ioraff pushes commits with author info stripped away [2026-10-05T00:44:11Z] maybe he could add Co-authored-by header with your name, idk [2026-10-05T00:44:48Z] tbh for me it's not a big deal, change is merged - good, i don't care how [2026-10-05T00:52:16Z] there were numerous proposals to address that, including maintainer file support [2026-10-05T00:56:16Z] also i could grant you write access, but i'm not in allowed_signers file, so I cannot give you trusted status [2026-10-05T00:59:53Z] it's another fucked up model, since if all trusted maintainers are absent there's no way to regain trusted status unless you force end users to temporarily disable verification [2026-10-05T04:43:17Z] does people even use the verification thing anyway? I know it had some issues in the past, which made users unable to pull, or whatever it was. it severarly broke the whole update process anyway. I dont recall all the details at the top of my head. I cant help but feel that the wholw signing of commits is redundant. we can easly check the commits and build files anyway, so trusting the commit [2026-10-05T04:43:19Z] itself seems redundant to me [2026-10-05T04:43:39Z] maybe on projects like grapheneOS, I can get it, but not on something like kiss [2026-10-05T06:38:39Z] guix people also use commit signing, except that signing and verification is mandatory here [2026-10-05T06:38:57Z] which is a part of the reason why initial guix pull is extremely slow [2026-10-05T06:40:08Z] another part is that using git as a database for package recipes was bad idea after all [2026-10-05T06:40:43Z] https://nesbitt.io/2025/12/24/package-managers-keep-using-git-as-a-database.html [2026-10-05T06:42:18Z] good read on that, unfortunately no guix mentioned which is imho best illustration of that mess [2026-10-05T06:42:54Z] ideally we should switch to a signed snapshot model where a signed archive of the repo is published and kiss update would conditionally fetch it and swap current repo with it [2026-10-05T06:43:51Z] i recall even dylan wanted to switch to this model, but for a different reason: to reduce pressure on maintainers due to constant catching up with package updates [2026-10-05T06:45:40Z] essentially it would be channels model with no git in the loop. [2026-10-05T07:09:52Z] mandatory even too. damn. the article does indeed point out some flaws. its funny how github even tells projects to stop doing certain actions, because its just too heavy. but I kinda get it. we should prefer solutions that is more lean. on all ends. despite some people wont give 2 shits if we hammer github's servers, because fuck microsoft, right? [2026-10-05T07:10:42Z] in any case, the snapshots seems like a possible fix for this. downloading a small tarball, as opposed to doing git pull all the time. [2026-10-05T07:10:50Z] i think alpine does this? [2026-10-05T07:12:00Z] despite being a binary distro that is. when you do `apk upgrade`, it fetches a few tarballs, and not some git repo atleast. so seems like their databases or whatever it is, is only hosted as tarballs [2026-10-05T07:12:10Z] i'm going to keep hammering github [2026-10-05T07:15:28Z] i figured someone would say that :P [2026-10-05T07:19:35Z] alpine uses APKINDEX which is essentially a map of available packages and their versions [2026-10-05T07:19:57Z] in our case this map would be repo snapshot itself [2026-10-05T07:22:52Z] right [2026-10-05T07:23:25Z] outside of that, iirc, they also selfhost their own gitlab instance, so in any case, they would only hurt themselves if they were to use only git here [2026-10-05T10:24:55Z] ye i think given kiss' scale this is basically a non-issue, performance/size wise [2026-10-05T10:27:35Z] the maintainer and signing thing can be discussed, sure, but i'm not sure how much a system designed for Linux Kernel development can't stand less than 15k commits combined for both repo and community [2026-10-05T10:28:10Z] hell, according to codeberg's own ui we're talking about like 25MiB [2026-10-05T10:29:57Z] also cloning repos here is a once-and-done thing, with incremental updates and... I could go on. I genuinely doubt we should migrate out of git for resource reasons [2026-10-05T10:53:43Z] kiss in of itself is probably as you said, a non-issue. the scale of repo and community is very small. repo is just shy of 25M, and community is shy of 20M. if you remove .git and related files, theyre less than 10M each [2026-10-05T10:54:06Z] ilt: thanks for the clarification, my underlying issue is that if tomorrow ioraff for one reason or another "disappears" then the kiss-community repo will simply "die" [2026-10-05T10:57:01Z] dery: if we compress said repos, they get really small even. community got down to 256k and repo got 564k. compressed with xz -9 [2026-10-05T10:58:39Z] sad_plan re removing .git: note that that folder contains a copy of all files. The tree is just for your convenience ;) [2026-10-05T10:59:18Z] the .git size *is* the true repo size. You can just archive that if you need to preserve a repo [2026-10-05T11:03:38Z] one solution would be to use rsync to sync the remote repo locally [2026-10-05T11:03:45Z] gentoo did that, maybe still does [2026-10-05T11:05:41Z] dery: i know, I was just showing a reference of filesizes for comparissons [2026-10-05T11:06:14Z] Vova: dunnno about gentoo, but some projects still does this.linux can be fetch via an rsync repo too iirc [2026-10-05T11:08:33Z] oh okay sad_plan, sorry, should've figured xD [2026-10-05T11:27:31Z] no worries dery :P