Ludovic Courtès <l...@gnu.org> writes: >> Specifically, the bulk of patch submissions in Guix deal with packages. >> Barring some core packages, perhaps Guix would be better served by >> splitting other packages into a separate channel. The organization and >> management of said channel could be optimized for tracking upstream as >> closely as possible. OpenSUSE's Factory model with OpenQA comes to mind > > That’s an idea worth considering in the long term, but it’s very tricky: > how do we decide what gets in?
Gets into what? Ring-0 is defined by minimality and ability to compile itself. Ring-1 could correspond to the packages included in the default Guix system installation. Everything else could go in a single separate channel (say, guix-extras), while Ring-0 and Ring-1 remain within the main 'guix' channel. > do we go as far as moving packages from Guix proper to another > channel? That is what I was proposing, yes. With this other channel being included by default in %default-channels. > how do we transition? This is the only possibly "tricky" part, but it's more complicated than "tricky" as long as we don't require there to be a seamless automated upgrade from current monolithic guix, to this future version where a large number of packages reside in a separate channel. > what API compatibility guarantees do we make? We could start by making the same ones we do today. >> As things stand today, the incentives for those without commit access >> are such that it makes better sense for them to focus on their own >> channels. This is a shame. > > Yeah. Having lively channels outside Guix is not necessarily a bad > thing though. Not necessarily, no. However, if these aren't channels that are widely known, then the experience for new users is worse. -- Suhail
