Re: On commit access, patch review, and remaining healthy
> On 15 Jun 2022, at 09:15, Arun Isaac wrote: > > 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. > If there is someone willing to maintain the packages, then in my opinion such restrictions shouldn’t be applied. I guess this would mean knowing who is the maintainer for each package in guix, but this could also be a team (reference the recent teams discussion). > 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 they should be removed. This could link to the maintainer comment above. If a package is identified as old or broken, then users could be notified, and after a “cooling off” period they are removed. This could allow for discussion about whether removal is appropriate, or whether someone else would step up and update the package. Under Gentoo (the distro I know well, having used it since 2004), obsolete and problematic packages are hard masked, and users notified why, and when removal from the repository will occur. The hard masking prevents new installations (almost - you can make some additional configuration changes to enable installation). Users then have a choice - support the resolution of the issues leading to hard masking, or move the package definition to a personal repository so it can continue to be used (at their own risk). Regarding rarely used packages - I wouldn’t remove these if there is a maintainer for them and they are still being kept up to date. If this no longer happens, then they are in the old/broken category. I guess the big question for me is “could this be automated in some way?” > I don't have strong opinions on these questions. I would love to hear > what others think. > I hope my comments are useful! Best regards, Paul
Re: proposal: guix-ment...@gnu.org list/alias
On 03/06/2022 12:53, jbra...@dismail.de wrote: I always use this website to remind myself how to use git send-email: https://git-send-email.io/ We could out that information in the guix manual or link to it. :) This is great - many thanks for sharing. I think a link in the manual would be very useful.
Re: Excessively energy-consuming software considered malware?
On 25/02/2022 16:14, Bengt Richter wrote: On +2022-02-25 14:04:34 +0100, Tobias Geerinckx-Rice wrote: On 2022-02-25 13:41, Bengt Richter wrote: And maybe also a mailing list called "guix-grownups" -- where casual adult language is accepted without triggering endless complaints. This is guix-grownups, although we accept grown-ups of all ages. Glad to hear it :) But the serious part of my post was --8<---cut here---start->8--- WDYT of starting a list called "guix-off-list" to provide a place for those who enjoy this kind of discussion? I do enjoy such discussions sometimes, but not on the same plate as debug tracebacks or beautiful code examples from the virtuosos. I don't mind single-line BTW or FYI or IMO: footnote references to out-of-thread content if the rest of the post contributes something and isn't just one line in a full quote. Having a "guix-offlist" would enable a reference like "IMO:guix-offlist: bitcoin explained by me ;)" --8<---cut here---end--->8--- The idea being to help factor off-topic discussion out of threads without interfering with people's desire to follow up with interesting ideas. Or not-so-interesting ideas :) Thoughts? Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity. I think it would be a good idea. There have been a couple of threads recently which have taken a lot bandwidth in the main lists where the topics have been interesting, but perhaps not on topic for the group.
Re: Documentation of what is appropriate for #guix?
> On 21 Feb 2022, at 19:10, raingloom > By the way, I think it's kind of silly that that is completely banned > from discussion. When I wanted help on getting my GPU to work, I > mentioned for reference purposes that I tried the proprietary driver > from The Forbidden Channel - and was subsequently warned that I must > not do that. I understand that the position taken by guix is more nuanced than that. The project doesn’t seek to control what you run on your computer, but won’t support your choice to run non-free software in the official channels. > Which I find ridiculous. You can't even discuss results > obtained by running closed source drivers and firmware, so how do you > debug the libre firmwares and drivers, when you have nothing to compare > against? But you can discuss these results elsewhere. > Also, I think people who want to overwhelmingly use free software but > need proprietary drivers for their computer to function should be > offered better help than "buy a new computer". I kind of agree with you here. I don’t want to obsolete perfectly viable hardware, but instead want to use it for its whole life. Next time I am in the market for new hardware, then I will have the ability to run libre-software as a pre-condition for purchase. > I think The Forbidden Channel should be raised to a status similar to > the AUR: it's recognized and its existence is documented, but all > responsibility is very explicitly disclaimed and support is relegated > to special channels. Users will find it even the way it is configured today. I don’t think it needs any sort of official recognition or promotion, as that will go against the project goals/rules (as I understand it). We should always be aware of the insidious nature of proprietary firmware/software, and work to eliminate the need for it, rather than indicating that its use is acceptable as a first choice. Best regards, Paul
Re: Excessively energy-consuming software considered malware?
> On 20 Feb 2022, at 10:07, Maxime Devos wrote: > > Guix has a policy against including malware[citation needed 2], and > furthering global warming[3] (and energy prices[4], if [3] is not bad > enough for you) seems rather bad behaviour to me. > > Would these miners be considered malware in Guix? > Greetings, > Maxime. To directly answer your question, in my opinion miners should not be considered malware in Guix. Much as I don’t like the adverse climate impact of miners and crypto, I think it is the thin end of the wedge of packages are restricted based on climate impact. I think we should stick to restrictions based on licence conditions. Of course, this is just a personal opinion, and has no more validity than your opinion!! Best regards, Paul
