Hi, Arun Isaac <arunis...@systemreboot.net> skribis:
>> 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 like them too! #1 is more involved than it sounds though: there would need some tooling and/or human intervention to merge things from the push branch to the pull branch. I don’t have a clear idea of how to do this. > 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. I’ve been wondering about that too. Clearly there’s a tension here. The main difficulty as I see it is how do we draw a line? For example, assume we came up two years ago with a policy to not include Rust packages and instead have them in a guix-rust channel. Two years later, Rust has become a dependency of a number of core packages, so we have to have Rust, or at least a large subset thereof, in the main channel. Then there’s the question of leaf packages (applications): how do you assess the usefulness of an application? How do you determine that an application is no longer used? > 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 think we do that from time to time, but it’s an entirely manual process. Sometimes a patch to remove a package triggers a reply with a patch to fix that package’s build process too (I’ve done that a couple of times :-)). What could help though is a dashboard, in Cuirass or in the Data Service, that would display packages that have been failing to build “for some time”. Thoughts, Ludo’.