Ian Eure <i...@retrospec.tv> writes: > A while back, I proposed splitting the nss package into two, one for > the ESR, and one for the rapid release. Because LibreWolf tracks the > Firefox Rapid Release channel, it needs a newer nss than what Guix has > fairly frequently, around 2-3 times a year. However, the nss package > is low in the graph, and upgrading it triggers ~15k rebuilds. > Splitting this into an infrequently-updated package tracking ESR, > which most things can use, and a separate package tracking the rapid > release channel, which LibreWolf (and anything else needing a newer > version) can use is IMO a reasonable way to balance browser security > updates vs. frequent huge rebuilds. I added the nss-rapid package to > unblock LibreWolf, with the intent that when the next nss ESR > happened, the nss package would get updated (and ungrafted). That > release happened a while back, and #73152 has patches to fully > implement the split and update nss to the latest ESR. > > The standard Guix process for updating packages low in the graph are > to push to a branch, let QA build substitutes, then > merge[1]. Unfortunately, QA is extremely bogged down, which means this > is effectively impossible, because by the time it builds the branch -- > if it ever does -- so much has changed in master that the work likely > needs a rebase, starting the whole process over again. > > What are the options for large updates like this? Thinking it > through, there seem to be three paths, in rough order of best to > worst: > > 1. Fix QA. I don’t know what’s wrong, or have a sense of what it > would take to fix. A one-week freeze on commits to let it catch up? > Moving to faster hardware so it can keep up with the pace of > development? Fixing QA seems like the best option, but also the least > clear and most difficult.
I'm also unsure what to do at this point. I'm more than happy to talk about the technical issues surrounding QA, but I think even if you were able to magically address all of the current issues I'm not sure that would really help. I think more fundamentally there's a lack of interest/buy-in, at least to support a system as ambitious as QA currently is. I'm obviously biased but when QA has been able to provide information on patches in the past, I've found that really useful. I don't want to be pushing patches/branches without that assistance, and while there have been people other than me that have worked on QA and the surrounding systems, it's been quite a few years now and as I say, I'm just not sure there's enough interest, and even if there is, that hasn't translated in to many people getting involved.
signature.asc
Description: PGP signature
