Hi Ludo,

On 2026-06-24 at 11:52+02:00, Ludovic Courtès wrote:
> On 2026-06-22 at 17:50+09:00, Nguyễn Gia Phong wrote:
> > I analyzed the official channel's dependency graph and it turns out
> > [...] if we do 300-dependent cutoffs, we would have 4 "rings"
> > going inward of 30722, 1775, 348 and 49 packages
>
> There are other barriers, having to do mostly with the inconvenience of
> synchronizing separate repos compared to a single monorepo, which would
> be a real step back IMO.

I hope you'll find the time to read through my wall of text,
but TL;DR I'm arguing that the monorepo is currently preventing
collaboration on updating packages deep down the dependency graph.
Synchronizing the inner channels (49/348/1775 packages) via releases
could allow us to calmly fix the breakages together rather than
competing for build farm resources:

On 2026-06-22 at 17:50+09:00, Nguyễn Gia Phong wrote:
> allow changes to land to <ring-i>'s master branch
> as long as they don't break their own ring.  Any breakage
> to their direct dependants on <ring-i+1>'s master
> must be filed as an issue proactively.
>
> This <ring-i+1>'s master however, depends on <ring-i>'s
> latest release version-n.  Once <ring-i>'s
> version-n+1 is out, <ring-i+1>'s master immediately
> switch to depend on it

and we join hands fixing that branch together.  Note that

On 2026-06-22 at 17:50+09:00, Nguyễn Gia Phong wrote:
> the master branch of any ring is not ready to be consumed
> by any user or other channel

and the official guix channel's master branch is an alias
to the rolling release of the outermost ring.

Kind regards,
Phong

Reply via email to