>ven. 13 déc. 2024 at 12:21, Suhail Singh wrote: > Is my understanding of your scenario as summarized below correct, could > you please confirm? > > There are some individuals who would be able to follow the instructions > to install Guix. However, these individuals wouldn't understand the > instructions to perform a "guix pull". Further, the number of such > individuals is greater than zero, and you are proposing that we consider > their needs when determining the release process for Guix. Correct. Except the number of such individuals is huge. Some are doing research, and they don’t need any more complexity, that they see as an extra overload : they’ll install guix, and start using it. That’s it. The more it becomes complex, the less they’ll be prone to try. > Assuming my understanding above is correct, wouldn't you agree that > (even) for those individuals what's most important is that there is a > _stable_ and _not-very-outdated_ release available? Correct again. At least, on a first contact with guix: one release every 4 months, for example, means using on average a two months out to date guix, which is fine. Take julia, for example. The cycle is : install guix, check julia, outdated, forget guix and use julia installer. > My (and I believe Greg's) contention is that following a time-based > release process achieves these objectives more effectively than > following a feature-based release process. I’m not against: higher instances decide. Anything, but a 2 years old release. Once again: sure, anything can be done, but it takes time and skills. And guix is already good and useful enough for most people to use it smoothly on a daily basis, solving lots of real life problems. Once they fall into the rabbit hole, they’ll pull substitutes from channels. But we need releases, first. -- Cayetano Santos GnuPG Key: https://meta.sr.ht/~csantosb.pgp FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682