Hello Ricardo, Am Tue, Apr 28, 2026 at 09:41:57AM +0200 schrieb Ricardo Wurmus: > I'm okay with merging now, but I want to point out that the timing is a bit > off.
in this case, merging r-team now might come at essentially no cost: It has been built itself, and python-team may not have advanced enough to have reached R yet (but here I am unsure, since I seem to recall that R itself comes quite early in the package graph; how can one check the distance of a package from the root(s) of the graph?). > If possible I'd like to merge the upcoming Bioconductor release updates > sooner this time. In the past I could always sneak in a few R updates, but > now that we do things more fairly, R updates (even when all they affect is > other R packages) need to wait in the queue for a month or longer. I'm not > proposing any changes; but it feels like a better process should exist. If you have actionable ideas to improve the process, please do not hesitate to bring them forward! I agree it is frustrating that "small" updates such as R (rather intermediate than small, but relatively fast building and confined) or KDE are held up by world rebuild changes. On the other hand, these world rebuild changes often have problems, which delay them and let the smaller ones sneek in, like r-team now. And it would also be a nightmare to have a queue of problematic world rebuilds; mixing them with simpler things gives a bit of breathing room. > I'll rebase r-team on top of master now and merge when ci.guix.gnu.org and > qa are happy. This time we have lots of fixes for i686 as well, so the > percentage of failing builds on i686 should drop significantly. QA will not handle the branch since it will give preference to python-team now that it has been evaluated. This could be changed by blocking one debbugs issue by another, but I do not feel that this is necessary: r-team was rebased yesterday, so I consider the branch ready from the QA perspective. So I think you can push to master as soon as you are happy with the CI picture. Andreas
