Slowroll: package stats + thoughts
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
On 2024-05-17 12:54, Bernhard M. Wiedemann wrote:
Maybe I should reduce the rate of updates for unreproducible packages...
Wouldn't this be effectively conceding that Slowroll users will be more vulnerable for those packages that are not reproducible? I'm also curious as to your opinion about whether using the longterm kernel makes sense in the face of research like this from CIQ? https://ciq.com/whitepaper/vendor-kernels-bugs-stability/ ? Looking at your numbers I'm finding myself worrying you're doing a ton of really detailed work for less gains than we hoped when we first talked about this concept
On 17/05/2024 14.57, Richard Brown wrote:
On 2024-05-17 12:54, Bernhard M. Wiedemann wrote:
Maybe I should reduce the rate of updates for unreproducible packages...
Wouldn't this be effectively conceding that Slowroll users will be more vulnerable for those packages that are not reproducible?
No, I would implement it as a factor on the delay and CVE-updates have a base-delay of 0. Though, it would mean, that users have to wait some days extra for other updates and bugfixes (that might bring new bugs, too). This is about approx 160 of 15401 packages. [1]
I'm also curious as to your opinion about whether using the longterm kernel makes sense in the face of research like this from CIQ? https://ciq.com/whitepaper/vendor-kernels-bugs-stability/ ?
Looking at your numbers I'm finding myself worrying you're doing a ton of really detailed work for less gains than we hoped when we first talked about this concept
There are many reasons to see things more positively: a) the article is about Redhat's 4.18 kernel, while kernel-longterm switched from 6.1.x to 6.6.x this year. 6.1 first appeared 2022-12-12 6.6 first appeared 2023-10-30 4.1 first appeared 2018-08-xx so we are much closer to master, which makes backports easier and more reliable. b) Also, this is not a vendor-kernel, but one with shared upstream long-term-maintenance. Including a public git tree. c) Additionally, just like in Tumbleweed, users can choose between kernel-default and kernel-longterm as they see fit. kernel-default remains the default. Ciao Bernhard M. [1] https://rb.zq1.de/compare.factory/build-compare-differed-builds.txt
participants (3)
-
Bernhard M. Wiedemann -
Bernhard M. Wiedemann -
Richard Brown