Hi,
> That’s why, I think the project should: > > 1. change the default branch of “git push” vs the default branch of > “guix pull”. > > 2. add a bit more of checkers on patch submission easing patch > review. I like and support both these ideas. Maybe, they are even long overdue! ;-) I would also like to raise a couple of more controversial suggestions: Should we restrict the set of packages that will be accepted into Guix? Currently, we accept practically any free software package into Guix. Should we limit the number of packages we will accept in order to ease maintenance? "Minimal" distros like Arch Linux do this, for example. The cons are that, say if we reject packages involving difficult languages (think javascript), we may alienate a section of our users (and potential users) and thus inhibit further growth. If we go down this route, Guix may never grow into an "universal distribution" like Debian is. Also, should we remove old/broken/unused/rarely-used packages from Guix? In the past, I have packaged and contributed very niche packages which probably no one else uses, and sometimes even I don't use anymore. But, these packages continue to stay in Guix and add to the maintenance burden. Should we have some policy to phase out such packages, especially if such packages break often? I mean, that there is no need to phase out an elisp package that builds trivially all the time, but what about more complex packages that take many many hours to maintain? I don't have strong opinions on these questions. I would love to hear what others think. Cheers, Arun
