>ven. 13 déc. 2024 at 10:52, Suhail Singh <suhailsingh...@gmail.com> wrote:
> Greg Hogan <c...@greghogan.com> writes: > >> We only need a release team and a documented release process. Releases >> should be scheduled rather than depending on other teams. What benefit >> is there to the Guix user when glibc or the default gcc are updated? >> You're only a "guix pull" away from updated packages. >> >> As I recall, one issue for past releases was having to freeze all >> development on the master branch. With the new teams-branches model >> the release-team branch is just another branch, moving to the queue >> when ready to cut a new release. > > My sentiments precisely. Thank you, Greg, for describing the situation > clearly. Let me just play the dummies advocate for a moment, before leaving the room to most experienced people: consider the army of regular potential users not necessarily concerned about monads, variants and derivations (or even substitutes). They will be doing `whatever install guix`, and then they’ll happily start using guix: with a bit of documentation, they’ll love it. This is all they need to know. Don’t tell them to do a `python pull`, `firefox pull` or `guix pull`. It comes to the same for them: they won’t understand. Once they get used to use guix daily, they’ll care about pulls, channels or asking support for guix on the cluster. -- Cayetano Santos GnuPG Key: https://meta.sr.ht/~csantosb.pgp FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682
signature.asc
Description: PGP signature
