Hello,
Am Tue, Apr 01, 2025 at 09:39:51AM -0400 schrieb Greg Hogan:
> QA shows no status ("Yet to process target revision") for python-team
> and core-packages-team (resurrected and now again the head of the
> queue).
I have just closed the core-packages-team issue, as it turns out that we
need to wait for an external patch. This frees one slot.
More generally, since now we have seen that by closing the bugs we can
leave and reenter the queue without losing our spot I would encourage
other teams to do the same. We can continue opening the issues as soon
as a branch starts, then wait for it to be built once; and if it is not
ready yet, we can close the issue again while working on getting the
branch in shape with the information obtained from the builds.
Probably we also need some human scheduler. In the past it has happened
that branches have clogged the queue although for a week or two nobody
was available to work on it. Having a person following the branches and
interacting with the teams to see where they are could help improve our
overall throughput.
As for QA there seems to be a problem; maybe the data service is
overwhelmed and does not evaluate the branches.
> Why are we wholly dependent on QA for this rather than also looking at
> CI? As Christopher Baines noted in response to my "Questions on
> Managing Patches and Branches" email:
> QA used to try and build the top 2 or 3 branches, but I changed this to
> 1 and limited data.qa.guix.gnu.org to just see the top 2 branches, in an
> attempt to better focus its limited resources on the top of the queue.
Chris has changed this back to two branches evaluated at the same time.
It is perfectly possible to also rely on CI when deciding to merge a
branch! Actually I am not exactly sure how to take this decision, with
tens of thousands of packages, it becomes difficult to compare the build
successes and failures on master and on a branch.
Currently we have no "merge manager", so it is up to the teams to decide
when they push their branch to master.
> The queue is a good idea except in the case where the merge window is
> months into the future when contributor availability is unknowable.
> And we need additional states in the machine so that teams can iterate
> without blocking the project.
Yes, somehow we are not there yet for a well working process!
Andreas
