Nguyễn Gia Phong <[email protected]> writes:
The documented process is for short-lived feature branches:
<https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html>
Andreas explained to me that the status quo of merge requests
being done by team is because of the potential high cost
of world rebuild: a complete one would takes around a week.
Feature branches are merged (and thus built) in a queue,
thus the disruption is more like the next branch has to wait
for its turn. It would not be great to make the waiting
really long (a month or more?) for example.
That process seems to focus on branches that are (mostly) ready to
merge. But since the break-and-fix migration we've been discussing
needs QA feedback, it sounds like the bulk of the branch work
can't begin until it's already #1 in the queue. And for an
iterative process (where each fix reveals failures in unblocked
dependees) that means several lengthy QA passes.
Am I missing some detail about how to make this feasible within a
short time window? Or does the plan hinge on an assumption that
substitute* breakages will be rare in practice?
Thanks,
Jason
