Dear fellow Geekos, You might have seen my https://en.opensuse.org/File:Slowroll-vs-tumbleweed-updates.svg that I drew up before development of Slowroll even started. And now I was wondering how it looks in reality, so I wrote a munin plugin script [1] to graph http://stage3.opensuse.org:17080/munin/opensuse.org/stage3.opensuse.org/slow... (today's snapshot img at) https://www.zq1.de/~bernhard/images/share/slowroll/slowrollstats-day-2024051... The blue line is counting the packages in Tumbleweed that got updates since the last version bump (2024-04-29). That increased by ~120 yesterday around 14:40 - there were actually 154 updates and the difference is from packages that have previously been updated since the version bump. Then we have the green area representing src-packages in the Slowroll update repo. If something receives multiple updates, it will count multiple times here, so that number could theoretically get higher than Tumbleweed's. But it does not atm. It increased by 72/d over the last two days. Mostly around 08:00 when updates go out (bunched together to not need multiple repo-metadata updates). In that number, we have two components: the bigger part are packages where Tumbleweed binaries are re-used, because our own build was found to be equivalent (per build-compare) - that is the red line in the graph. +42/d here. The second part (yellow) is Slowroll-specific builds (+30/d) this number could be lower, if we had more reproducible-builds (e.g. for python3). As divergence between Factory and Slowroll grows after a version-bump, this number is expected to get a larger share. It would be beneficial to keep this number low, because at the next version bump, we need to discard these builds and then zypper needs to pull more updates. One conclusion from this graph is that there is room to improve the time until we get CVE-fixes from Tumbleweed into Slowroll. [2] Currently it is ~18h delayed and I think, we could get it down to 3h (for packages that don't take long to build). Another conclusion is that more reproducible builds will help reduce the amount of undesirable Slowroll-specific builds. Maybe I should reduce the rate of updates for unreproducible packages... Ciao Bernhard M. [1] https://github.com/openSUSE/slowroll-tools/blob/devel/extra/munin-slowrollst... [2] https://trello.com/c/2nj0UPHL/31-event-driven-updates