Am Wed, Sep 17, 2025 at 11:46:56AM +0200 schrieb Gabriel Wicki:
> On Wed, Sep 17, 2025 at 11:36:42AM +0200, Andreas Enge wrote:
> > for the time being, branch push requests are still handled through
> > debbugs, and audio-team is an existing branch that is queued on QA:
> >    https://qa.guix.gnu.org/
> i see.  i think i remember someone mentioning that ETA for this jobset
> to build was something along half a year?

It is much less, but can be 3 months or so; core-packages-team was an
outlier due to being postponed when problems were found.

> > Probably a bit of rebasing would be useful.
> i'll gladly do that, but guess i can still put it off a bit until the
> jobset gets a *little* closer to building

Sure, in particular since it contains only a few commits.

This also makes it a candidate to be piggy-backed together with another
big rebuild, such as mesa-updates; but this would have to be discussed,
since a big problem with audio-team would then hold back the merge of
mesa-updates.

This is maybe the moment to comment on my world-rebuild branch trial.
In this branch, I had regrouped about a dozen commits leading to big
rebuilds and most of the time not being covered by any team, and almost
all of the distribution was rebuilt as a consequence.
I am not exactly sure what conclusion to draw from the experiment, however.
- As much as possible, I had tried to do a "guix rebuild -P1" for each
  of the changed packages, which was quite a bit of work to prepare each
  commit. Some of them had too many dependents to make this possible.
  For others, even on master the dependents did not build, so the result
  was not conclusive; I still think that we should work more aggressively
  towards 100% of packages building so that every failure after a change
  is a new failure, period.
- The work has paid off in the sense that the branch was merged without
  problem (unlike other branches that in the end did break things, but
  the comparison is unfair since those other branches usually had more
  and more risky changes, which we also need to make from time to time).
- The amount of required building work was inordinate with almost a
  complete rebuild after touching only a few packages.
  I merged 12 days after the branch had started to build; but this is
  more than the time needed for the world rebuild, since it was quite
  delayed by bigger changes on master that took precedence, and the delay
  also led to me not being around for merging on the day the builds
  finished.

For a better balance between energy spent on building and the amount of
changes that go in, since everything went well, one conclusion could be
to add more commits to a world-rebuild branch, say two dozens next time.

What did pay off was to curate the commits that go in, and to close the
window of opportunity after that - it avoided the quicksand of an ever-
changing branch that we had with the former core-updates branch, which
everybody involved remembers with a shudder (core-packages-team also had
some of this feel, which made it rather unpleasant to work on the branch).

Andreas


Reply via email to