How "ready" do branches need to be in the "request to merge" queue? Our documentation [0] includes both of the following statements:
"Once a branch is at the front of the queue, wait until sufficient time has passed for the build farms to have processed the changes, and for the necessary testing to have happened." "Sometimes, a branch may be a work in progress, for example for larger efforts such as updating the GNOME desktop. In these cases, the branch name should reflect this by having the ‘wip-’ prefix. The QA infrastructure will avoid building work-in-progress branches, so that the available resources can be better focused on building the branches that are ready to be merged. When the branch is no longer a work in progress, it should be renamed, with the ‘wip-’ prefix removed, and only then should the merge requests be created, as documented earlier." [0] https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html It seems that we are at the point where the queue has grown so long (more than "2 months" for the python-team) that teams do not want to lose their position in the queue. Also, mass rebuilds require the build farm, both due to the number of builds and that builds are not always possible on user hardware (even for x86-64). Is only the branch at the head of the queue being built? If not, why not allow other branches in a ready state to merge? And if one branch does block the queue then perhaps we can create a second fast-track queue for branches not performing world rebuilds. What is the distinction between the "qa" service and "ci"? Does c++ need a specification on ci.guix.gnu.org? Now, the c++-team branch is no longer in a ready state because I discovered additional work (ctest has no concept of a "test-target" and many packages were silently skipping tests). I am confident that I will have this fixed shortly, certainly within the time that the queue clears, but I see that I am also contributing to the collective problem. Also, the longer team branches sit in the queue, the more time to accrue updates, the more we start to look like the old days of the staging and core-updates branches. Greg
