Re: Guix user statistics and upstream/downstream dependencies
Hi John, John Kehayias writes: > For the first, maybe someone has some unofficial surveys or things > like download stats, mirrors, etc.? I'm aware of https://openhub.net/p/gnuguix which gathers simple statistics on contributions. There's also https://repology.org/ for statistics on package availability if that matters. > I know Guix is used for some research, high performance computing, > ...what else do people know of or anywhere we mention this? (Would be > great to have a "powered by Guix" on our website, by the way!) Off the top of my head, besides usage in HPC as well as research, guix is used as a part of the development workflow of software projects (if I recall this right nyxt as well as bitcoin are two more well known of them I've recently read about). I also read about gov.uk guix usage somewhere, though I'm pretty certain other folks on this mailing list know more about it and its details than I do. -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Guix Days: Patch flow discussion
Hi Guix, Tomas Volf <~@wolfsden.cz> writes: > Or, to put it in a different way: The problem is not that too few patches get > merged. The problem is that too few patches get reviewed. I'd say that both things stem from the same premise, a disproportion of available resources to the work that exists. This is not something specific to Guix as a project, but can be observed in many other projects as well (I couldn't name one larger free software or open source project without this issue, but could easily name some where this applies). The interests of a contributer sending a patch sometimes may not align with the interests of the project/sometimes may not align with the interests of commiters and so on. This happens and is a pretty common reason for contributions being ignored and I see that as somewhat a default modus operandi in many projects. Especially if available time is a rather sparse resource. I'd like to suggest to explicity refer to pragmatic ways forward in Guixes Contributing manual section that don't rely on the availability of other peoples (in this case committers/reviewers) time while empowering contributors to use their changes in a good way if a patch doesn't make it in/a bug report gets no reaction? Guix offers ways to use packages outside of Guix proper in a pretty feasible and maintainable way (manifests, setting up channels), maybe promoting them as an alternative to having things in guix proper "as soon as possible" (as that's not the only option to have things in a usable form) would be beneficial. -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: GNU Shepherd 0.10.3 released
Hi Ludo, Ludovic Courtès writes: > We are pleased to announce the GNU Shepherd version 0.10.3, a bug-fix > release of the new 0.10.x series, representing 51 commits over 6 months. Congratulations on the release & thanks to everyone that have worked on this for their work! > ** New #:respawn-delay parameter to ‘service’ > (<https://issues.guix.gnu.org/64665>) > > This specifies a delay before a service is respawned. Its default value is > given by ‘default-respawn-delay’ and defaults to 100ms. Until now, services > were respawned immediately. I've a couple of services defined that benefits from defining a respawn delay, thanks for this! > ** Fix portability issues to GNU/Hurd > > Previous versions in the 0.10.x and 0.9.x series did not work on GNU/Hurd. > This is now fixed, although some features are still implemented in a > suboptimal way. This also sounds great, always happy to read news about the hurd. -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Guix at 37C3 Chaos Communication Congress in late Dec?
Hi Fabio, Fabio Natali writes: > Quick update re 37C3, I ended up registering 3 self-organised sessions As the 37c3 has ended today, were the sessions fun so far/did everything go well? Curious to hear how things went and if you were able to reach new folks interested in Guix at the event. -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Guix at 37C3 Chaos Communication Congress in late Dec?
Hi Matt, Matt writes: > Maybe there's another time people in Hamburg could meet up? I don't think there's something Guix-specific in Hamburg yet, you could try reaching out to the local branch of the CCC there and see if anyone at their local gatherings is interested in it though (I'm not too familiar with the CCC in Hamburg though, so I won't make any assumptions on wether or not there'll be folks interested in Guix in particular, but it may be worth a try). I've occassionally read about other Guix meetups on here, some of them being online events, so maybe participating in those could be your best bet for a social event if there's nothing local. Others than that I've read here[0] that this years reproducible builds summit was in Hamburg and another event in Berlin; though I'm not aware of any regular guix meetups in Germany. [0]: https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00085.html -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Guix at 37C3 Chaos Communication Congress in late Dec?
Hi Fabio, Fabio Natali writes: > I was wondering if you might be aware of any Guix-related event/session > (talk, assembly, self-organised session, etc) happening at 37C3? I > wasn't able to spot anything when flicking through the event portal⁰. I won't be at the 37c3, but have regularly attended most chaos communication congresses of the last decade before, well, 2020. Generally speaking I haven't seen that many Guix related things at those events; so your best bet would probably be to do a self-organized session, e.g. some sort of a users meet-up as they're relatively easy to organize there. -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Banana Pi BPI-R4 support?
Hi Attila, Attila Lendvai writes: > MediaTek MT7988A (Filogic 880) I don't know too much about the Filogic 880, but from my experience the number of SBC platforms that work entirely on free software is sadly pretty sparse. > with that in mind: how hard/hopeless would this task be? both 1) > technically (if we ignore any possible use of blobs), and also 2) > regarding the FSDG standard? Technically it *could* be as easy as easy as building an image around a custom u-boot variant package and a linux-libre-arm64-generic kernel package. There are some examples for this in the gnu/system/images (rock64 and some other iirc) and gnu/system/examples (for beaglebone black at least) tree of guixes repository for reference. Realistically my guess would be that you'd run into firmware/binary blob issues and GNU FSDG issues rather quickly. -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
Hi Katherine, I haven't had too much time lately in regards of the survey, but hope I'll be able to commit more time to it throughout the next weeks. Thanks for reviewing the first rough draft of the questions! Katherine Cox-Buday writes: > Does the GNU project have a "general translation" team? > > Maybe some of our Guix community members who speak multiple languages > would be willing to translate the survey into their primary language? I'm not too familiar with the structures of the GNU project; but there's a page mentioning translation teams for several languages at least[0]. Don't know how active these teams are, so maybe reaching out to other community members on this list would be a better bet? > My opinion is that we should not do free form questions for this first > time. We're new at this, we have enough topics to cover, and the > topics we are covering seem to cause a lot of discussion (that's good) > which could lead to a lot of text to read through. Agreed, having quantitative questions only already seems like a good amount of work; even though free form would be quite interesting, that's, as you said, out of scope for the first survey. > Have you done any more research on what other communities are doing? I did! Hope I'll be able to write a good cohesive summary of my org-roam notes on this to share in this thread soon-ish. > What are next steps? I think Simons idea of collecting our questions somewhere and improving those until we're happy/able to start the survey period sounds like a good plan. If time permits, I'll put the rough list of questions we have now in a .org document and open an issue containing them; so we have a place where the survey questions can be edited/improved/discussed. WDYT? [0]: https://www.gnu.org/server/standards/README.translations.en.html#teams -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Need people to help with kernel updates
Hi Leo, Leo Famulari writes: > It seems that linux-libre 6.6 will be released soon. Yes, probably within the next(?) week if I read this mail[0] on lkml right as there'll probably be a rc8. There already seem to be a 6.6 branch in the linux-libre project introducing the deblob scripts: commit 8437b2928c7fd032657f571974c004130f940956 (HEAD -> scripts/6.6, tag: scripts/v6.6-rc7-gnu, origin/scripts/6.6) > Would anyone like to try their hand at packaging it for Guix? Wilko, do > you feel up to it? Sure thing! I'll start packaging it as soon as 6.6 is released and the deblob scripts for that release are ready. > As I mentioned previously, this requires a bit more work than minor > kernel upgrades because the kernel configs need to be updated. > > I'm happy to assist with this, give advice, etc. Thank you for this, I'll reach out if I experience any blockers or need help during the process of packaging the 6.6 release. [0]: https://lore.kernel.org/all/CAHk-=whqsbGgnoeYeEuP9fabaZrpPDA=sysmbe3tfqqqvmh...@mail.gmail.com/ -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Golang mudules to follow common grouping
Hi, Sharlatan Hellseher writes: > I think it's time to split (gnu packages golang) into some logical groups, see > Python, Lisp for example. > > Thoughts? IMHO this sounds like a good idea as it would improve the maintainability of golang packages in the long run. We have 487 package definitions right now: (~/devel/guix-devel/gnu/packages) λ rg -c 'define-public' golang.scm 487 which already seems quite laborous to split into logical groups (while getting the copyright information right as well and maintaining the gitlog history etc.); so it probably classifies as a task that should be tackled sooner than later as it'll cause more work over time the more golang packages exist. -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Need people to help with kernel updates
Hi Leo, Leo Famulari writes: > I pushed your patches as 06acda9715711c406f30b3a314387002244d8792 Thank you for this! > Overall, the fact that qa.guix.gnu.org is successfully building across > so many architectures means that we have a strong foundation for the > future of building kernel packages in Guix. This sounds good; good to see how many builds were actually succesful on guixes QA! > Thanks you for taking the initiative to write the patches and manage QA > for this latest round of updates! > > I'm curious, now that we've done a round, do you have any thoughts about > the work so far? Thanks to the scripts you've provided and the initial explaination you've given it was fairly easy to pick up the work of bumping the minor kernel versions so far. I already followed new kernel releases closely before, so figuring out when actions are required (as in when new minor versions were available) wasn't too much of an issue. With 6.6 around the corner soonish, I wonder how making a new kernel config for that major release will go/what there'll be to learn in that regards. Until now the whole process seems to be quite easy to pick up, but does require constant recurring attention around each new minor release. There's been a 6.1.58 stable release a few hours ago[0], with changing mostly affecting the NFS subsystem (changes being almost exclusively reverts of commits). I created a patch[1] for this, if you'd have a minute to spare (or anyone else with appropriate rights to apply it on the kernel-updates branch; as I can't do it myself), we could see if it builds/merge it to master later on if it looks good. [0]: https://lore.kernel.org/lkml/2023101518-subscript-entity-be71@gregkh/ [1]: https://issues.guix.gnu.org/66568 -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Proposal: Differentiate products more clearly (Cycle 01)
Hi Luis, Luis Felipe writes: > This is a proposal to help differentiate Guix, the package manager, > from Guix System. This sounds like a good plan. > Background: As far as I understand, Guix was supposed to be GNU's > package manager, and GNU was supposed to be the operating system: two > products with two different websites. Unfortunatelly, that didn't > happen and the Guix website became the home for two products: Guix, > the package manager, and Guix System, a distribution of the GNU > operating system. Since then, both products have been presented almost > as a single one in the website. Probably as a result of this some > people call both products by the same name (Guix), Splitting up the website in a "guix for package management" and "guix as a operating system" part sounds reasonable. I've reread the landing page and to me, one of the biggest issues it currently has is, that it vaguely describes attributes, but doesn't work well as a Guix primer for either Guix as a package manager or Guix System as an OS. > and some other people don't understand what «Guix» is by skimming > through the home page. This seems directly related to the landing page not being too great as a brief introduction for Guix. If I'd be a first time visitor of the landing page, I'd probably have questions along the realms of: - what is Guix? - why should I use it? what can it do for me/in my field? - do I want to use guix as a package management/or Guix System as a OS? On that note, I really appreciate and like how Guiles[0] landing page works in this regard. As it is written in a pretty clear language and answers pretty straight forward: - What Guile is. - What it has to offer/what potential common use cases are. - Usage examples on how to get started. reading it provides yet enough information to get a grasp of what Guile is and how to use it/how to get started and what to look up next. While writing this mail I also had a look at the mockups of potential solutions you provided; and they do address these points in a pretty good way, especially as it uses a clear and straight-forward language! [0]: https://www.gnu.org/software/guile/ -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Need people to help with kernel updates
Hi Leo, "Leo Famulari" writes: > On CI, at least the 6.5.6 kernel package was built: > > http://ci.guix.gnu.org/eval/831643 The current iteration of updates[0] to: 4.14.327: longterm 4.19.296: longterm 5.10.198: longterm 5.15.135: longterm 5.4.258: longterm 6.1.57: longterm 6.5.7: stable seems to be good again at least, as in: - it builds locally - QA[1] looks okayish as far as I can tell (no lint warnings, build statuses look good on more common ISA) even though we still seem to have partial build failures on some architectures: - x86_64-linux and aarch64-linux build completely fine according to QA - without any failures or unknown status - i686-linux has mostly succeeding builds, 5 unknown - armhf-linux has one failing and 18 unknown [0]: https://issues.guix.gnu.org/66455 [1]: https://qa.guix.gnu.org/issue/66455 I don't know if some of that is to be expected for less common ISAs or if it could be beneficial to invest time in looking into e.g. the armhf-linux build failures. -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Need people to help with kernel updates
Hi Leo, Leo Famulari writes: > Yes, the hashes of the kernel source code and linux-libre's "deblobbing" > scripts have to be updated. I have some scripts that fetch and calculate > the hashes (attached). Thanks for sharing these scripts with me, I've had a look into them to get familiar with them & so far they seem pretty useful! > I'm not a kernel developer or expert. The upstream defaults for kernel > 'settings' are sensible. We usually differ from the defaults by enabling > support for lots of hardware. Sounds reasonable, supporting as much hardware as possible seems feasible for a generic config for a kernel build. > My impression is that x86_64-linux is by far the most popular platform > for Guix users, and then aarch64-linux, and then the rest. > > Architectural support is a problem of the type "What came first: the > chicken or the egg?" So, if anyone wants to improve support for these > other architectures, you'll be making an egg from scratch, in the hope > that people will start using the kernels :) Yes, imho we're still a few years away from seeing more RISC-V systems. In terms of ARM, I do see some u-boot packages for SBCs in bootloaders.scm, so I assume people are using them, but I agree that x86_64 should have by far the biggest share. > I invite you to choose, email or IRC :) Mail sounds good to me! (I'm rather sporadically active on IRC, so mail usually is a better bet) > To summarize, this work needs regular but brief attention. There's not > much feedback from the community, so we do our best and make sure the > basics work before pushing (reboot and connect to the internet). I'm > eager to help grow the community of people working on this, and can help > answer questions and give advice about things like the configs. Thank you for this. I've seen the recent thread on making linux-libre 6.5 the default kernel[0] and will have some time at hand later on today. I could try to prepare a patch set doing this to get more familiar with the process, which would then need a review. WDYT? [0]: https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00027.html -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Need people to help with kernel updates
Hi Leo,
Leo Famulari writes:
> For a few years, I've been handling updates of the linux-libre kernel by
> myself.
First of all: thanks for doing this!
> The work itself is fairly mechanical and updates occur about once a
> week. It takes about 30 minutes to prepare the patches and push them to
> CI or send them to the mailing list.
I could imagine myself helping with these tasks. Practically this means,
that, whenever a new linux-libre minor update is being released, the
versions in linux-libre-* packages in gnu/packages/linux.scm have to be
bumped/a patch has to be sent?
Also: Is there anything to know/to have in mind when generating a new
kernel config for major releases?
> There is plenty of support for the CI and QA infrastructure to build the
> kernels, so you don't need a powerful computer.
How's the coverage for different ISA? Do the current CI jobs also cover
all the architectures we seem to support:
'("x86_64-linux" "i686-linux" "armhf-linux"
"aarch64-linux" "powerpc64le-linux" "riscv64-linux")
or are there cases where it could be beneficial to build locally first
using:
guix build -s $ISA linux-libre
for certain ISAs? I could use my workstation for this, if there's a
benefit to it.
> If you want to join in, please reply!
How would the communication around this be organized? If n>=2 people are
trying to work on the same set of tasks duplication may happen.
--
Kind regards,
Wilko Meyer
w...@wmeyer.eu
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
'd say, that it could be beneficial to ask for usage as long as it helps to map out the background of guixes users. I wouldn't go too much into detail, but this subset of questions on general usage I shared before (and maybe a question on familiarity with Guile/Scheme) would still provide value: >> - Why do you use Guix? (freeform) >> - Where/on what platform do you use Guix? (Guix System, on top of other >> distributions etc.) >> - How many years have you been using Guix? >> - In what context do you use Guix? (academic, work, private etc.) >> - What do you use Guix for? (packaging, systemconf, reproducible >> research and so on) >> - Have you ever considered to stop using Guix, if so why? (freeform) >> - Which features keep you using Guix? (should be a list with optional >> freeform) >> - To extend guix packages/work on new packages, you... >> ...upstream to guix proper >> ...maintain a fork of guix proper >> ...maintain your own guix channel >> ...provide a guix.scm for the respective projects to assess the questionees background better/be able to give more context. WDYT? -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
orm option) - Have you contributed to Guix in the past and stopped, if so what were your reasons? (list of options with freeform) - When was your first contribution to Guix? - Can you give a rough estimate on your number of contributions? - What resources have you used for help to prepare a contribution? Guix Manual IRC Mailing lists and so on... - What text editor do you use to hack on Guix? *** Misc. - If there's one thing about Guix you could change/improve, what would it be? - What would you see as the best, what would you see as the worst area of Guix? - Anything missing in this survey? What topic would you like to see covered? -- Kind regards, Wilko Meyer w...@wmeyer.eu
Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
Hi Guix, I haven't had enough time to read up on every topic that has been mentioned in the "How can we decrease the cognitive overhead for contributors?" discussion as at some point it got quite a lot to follow. At one point[0] there was a discussion on having a survey to get a better picture on and quantify what potential blockers are to engage with/contribute to Guix; which seems, if done right (as surveys have to be carefully crafted), a good idea; especially with the prospect of repeating it annually as a means to check if issues got better/priorities in Guixes userbase change and so on. If there's a consensus on doing this, I'd be happy to contribute some of my time to get things going (would creating a issue on guixes bug tracker for this topic be a good idea? how are these non-code contrib. topics handled?). Before writing this mail, I had a look on how other projects handle these kind of surveys, in particular: - the emacs user survey[1] - the nix community survey[2] - the curl user survey[3] - the fennel survey[4] I identified a few key themes that could be useful for a guix user survey as well. I plan on doing a more extensive summary on this later this weekend if my time allows it, for now a loose collection of ideas/list of what, in my subjective opinion, stood out and what most surveys had in common should do to hopefully get a discussion on this started: - the emacs user survey specifically asked for elisp profiency; mapping out the Guile profiency of guixes community could be feasible. - fennel as well as emacs had questions on which programming languages their community uses; in the regards on recent discussions on guix-devel on developer ecosystems[4] this could help to identify if there are any shortcomings in providing importers/packages for certain languages that may be used by guix users. - the nix survey specifically asked for the environments and context nix is being used in; it'd be interesting to see where and for what purpose people are using Guix. - most surveys had, some more some less extensive, demographic questions and questions mapping out how many years people have been programming. Specifially in the lights of the original discussion/regarding contributions: - I think that the "Where do you discuss Fennel or interact with other Fennel developers" question of fennels survey should be asked for guix as well, to get a grasp on which platforms are being used to discuss all things guix. - the curl user survey[6] did a pretty good job in mapping out what prevents users from contributing (p.20) as well as mapping out what areas of the project are regarding as good/which have room for improvements (p.24-26) - fennel asked for "the biggest problems you have using Fennel", it had a "If you haven't hacked on Fennel itself, why not?" question as well. I personally think this could be good to assess potential pain points/blockers for Guix as well. Fennel also asked for "favorite features" which could be a nice way to map out which parts of Guix are popular. Last, the nix user survey allowed free-form responses. Having a qualitative research component to a survey could help getting better results (especially when identifying problems in using guix/blockers in contributing and so on); but evaluating these is pretty time extensive and dependant on how much resources people have to compile a list of findings/results from a prospective survey. What could the next steps be to get this going? [0]: https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00086.html [1]: https://emacssurvey.org/ [2]: https://discourse.nixos.org/t/2022-nix-survey-results/18983 [3]: https://daniel.haxx.se/blog/2022/06/16/curl-user-survey-2022-analysis/ [4]: https://fennel-lang.org/survey/2022 [5]: https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00152.html [6]: https://daniel.haxx.se/media/curl-user-survey-2023-analysis.pdf -- Kind regards, Wilko Meyer w...@wmeyer.eu
Guix User Survey?
Hi Guix, Katherine Cox-Buday writes: > > I think the easiest way to start, and something that's actually pretty > effective, is to start doing annual surveys, e.g.: > > - https://discourse.nixos.org/t/2022-nix-survey-results/18983 > - https://survey.stackoverflow.co/2023/ > - https://tip.golang.org/blog/survey2023-q1-results > I think this is an excellent idea to have a means of mapping out guixes community and values. This years curl user survey[1] asked specifically what prevents curl users from contributing (p.20) as well as asked to rank the "best/worst" areas (p.24-26) of the project. I think that asking the broader guix community these specific questions could be beneficial in answering the initial question of this thread on how to decrease the cognitive overhead for contributors/lowering the barrier to contribute to Guix. Furthermore, it could also be beneficial to collect informations on what hardware the guix community uses (running a hardware survey was at least mentioned once on this list[2]) and what people are actually doing with Guix (the "Guix and the developer ecosystem" discussion[3] could be related to that). > With a survey you can quantify these opinions and say things like "X% > of people would like the current contribution process to remain the > same. Y% of those are committers." Right now we only do have the opinions of folks reading and actively posting to the mailing list; which may be a way smaller group than guixes actual userbase. At least I'd say it's safe to assume that there may be guix users who do not read guix-devel, as well as those who read this list but don't actively post to it. A survey could lead to more representative results in that regards, as it may enable more folks to participate. As far as I know NixOS uses a hosted LimeSurvey for their surveys, which should be free software; even though it doesn't seem to be packaged for Guix yet. If there's a consensus that such a survey may be a good idea, I'd be happy to contribute to it; even though I'm not familiar enough with the governance part of guix as a project to get things started (I suspect discussing this on this mailing list is a good start?). [1]: https://daniel.haxx.se/media/curl-user-survey-2023-analysis.pdf [2]: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00297.html [3]: https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00152.html -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: How can we decrease the cognitive overhead for contributors?
Csepp writes: > > Doesn't Magit have a generic forge integration? > There's forge.el[1] which is part of the magit project. It's not too generic though, as it only supports Gitlab (which applies to self-hosted instances/hosted instances such as e.g. salsa.debian.org) and Github[2]. Magit itself doesn't come with forge support iirc. [1]: https://github.com/magit/forge [2]: https://magit.vc/manual/forge/Supported-Forges.html -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: How can we decrease the cognitive overhead for contributors?
Hi Attila, Attila Lendvai writes: > i couldn't even find out which tools are used by those who are > comfortable with the email based workflow. i looked around once, even > in the manual, but maybe i should look again. I can only speak for myself here, but I tend to use magit[0] from inside emacs for most of these things (sometimes git format-patch and git send-email directly on my shell). In magit there's: - magit-am-* to apply patches[1] - the magit-patch-popup to create patches[2] I've written a few elisp functions on top of that, to be able to e.g. directly apply a patch from a mail I've received (I use mu4e[3] as my mail client) more conveniently. My set-up is far from being perfect and quite simple, but more often than not perfectly enough for most of my contributions to mail based projects. More generally speaking, there's a pretty good tutorial[4] on git-send-email written by the sourcehut folks, which also includes steps on how to get git-send-email going on Guix. I usually refer to that when being asked how to get started with a email based git workflow (I'm by no means an expert on using said workflow (so I'd also be interested on how said workflow looks like for other people on this mailing list), I however do know enough to ocassionally use it conveniently enough for my use-cases). [0]: https://magit.vc [1]: https://magit.vc/manual/magit/Maildir-Patches.html [2]: https://magit.vc/manual/2.13.0/magit/Creating-and-Sending-Patches.html [3]: https://djcbsoftware.nl/code/mu/mu4e.html [4]: https://git-send-email.io/ Best Regards, Wilko Meyer
Re: How can we decrease the cognitive overhead for contributors?
Hi Katherine, Katherine Cox-Buday writes: > That last part is what I wanted to discuss, because > that's the part > that prevents me from contributing more than I do, and I think there are > probably others whom are impacted by this. Yes, I'd actually love contributing more to Guix; but even with some familiariaty with a patch-based workflow; Guix, from my perspective, resides on a higher end of effort in terms of overhead/time spend until a patch series is ready. I tend to have plenty of half-way finished/not thoroughly tested stuff on my own (local) guix channel, but wouldn't want to submit "works for me"-ish patches soliciting the attention and time of reviewers that could probably be utilized better. I don't have a particular solution for this, but I think it's important to make contributions easier, as requiring a certain time privilege as it does now doesn't seem to be feasible. Another thing to consider may be the time until a patch is being discussed/merged. I don't have any metrics for Guix, but from my experience delayed responses are usually one of the major issues on why first-time contributors don't become recurring contributors in other projects. Nix seems to address this here[1] as well. Having a tag for first time contributions, which is what nixpkgs seem to have, in debbugs/on issues.guix.gnu.org could probably be beneficial to address this issue for Guix as well. > I signed up on Savannah with the intention of applying to be a > committer. > Savannah closed my account one or two days later due to inactivity. Happened to me as well, never tried signing up again afterwards. > I don't use the email-based patch workflow day-to-day, so this is > another > area where I spend a lot of time trying to make sure I'm doing things > correctly. I feel like the advantages of a email-based workflow nowadays is more on the maintainer side of things (as managing large projects is easier using email/threaded discussions instead of the comment-based mode of discussions the MR/PR web based processes offer), as for a vast majority of potential contributors it seem to rather complicate things as most people seem to be rather used with said web-based workflow. > * It's OK to make lots of mistakes IMHO this is a pretty important point. > * We could support a managed web-based workflow This would, in addition to the email-based workflow, make at least that part of the contribution process more accessible for a larger crowd. As others have already mentioned in in this thread: sourcehut seems to be working into that direction. [1]: https://discourse.nixos.org/t/showing-first-time-contributors-some-love/29105 Best Regards, Wilko Meyer
Re: Updates for Go
Hi Katherine, Katherine Cox-Buday writes: > Thank you for volunteering! > > I'm not aware of a TODO list anywhere other than the issue tracker > (https://issues.guix.gnu.org/search?query=golang+is%3Aopen). I've spend some time during the last days getting familiar with the go-build-system in guix and how it works internally, and while reading guix/build/go-build-system.scm I actually found such a list as commentary from 2018-01-06 (e3900a4d64e): ;; TODO: ;; * Avoid copying dependencies into the build environment and / or avoid using ;; a tmpdir when creating the inputs union. ;; * Use Go modules [4] ;; * Re-use compiled packages [5] ;; * Avoid the go-inputs hack ;; * Stop needing remove-go-references (-trimpath ? ) ;; * Remove module packages, only offering the full Git repos? This is ;; more idiomatic, I think, because Go downloads Git repos, not modules. ;; What are the trade-offs? this is probably not too relevant for now, but maybe it'd be good to see which of these bullets still apply and move those as issues to the issue tracker (if they aren't issues yet, haven't checked this). > Personally, I think the immediate emphasis should be on making > bringing our Go ecosystem onto a supported version of Go (ideally > 1.21.0). If there is consensus on that, then ensuring that some of our > packages with larger dependency graphs compile would be a good place > to start. I'd definitely agree on that, bringing guixes go ecosystem to 1.21.0 should be a good and reasonable start. > It would also be useful to get https://issues.guix.gnu.org/65317 (add > go-1.21) reviewed, even if you don't have commit access. I've been > exercising the package since I sent the patch, and I think v3 is > correct (at least functionally), but it could use more exercising and > a review of the scheme code. I'll try to have a look into this later on. Have to keep this mail short as my lunchbreak's almost over; but will definitely spend some time on this later on this day! Best Regards, Wilko Meyer
Re: Updates for Go
Hi, Katherine Cox-Buday writes: > Even if you dislike Go, but can work your way through a package, > please consider signing up! I started picking up Golang for work related use recently again; have been somewhat regularly writing it between 2015 and 2018-ish, but always favored using something like C or Rust over Golang. That being said, I'd actually be willing to put some time and effort into Guixes Go ecosystem; even though I haven't been on Guix for that long and would probably have to read through prior contributions to golang.scm to get the gist on how the go-build-system and packaging all things go work and to contribute something useful. Is there a list of current TODOs somewhere? Or would one start by bumping packages to build with a more recent/non-EoL go version and see if that works out? Best Regards, Wilko Meyer
Re: Guix and the developer ecosystem
Hi, Distopico writes: > 2. Do you see developers as a potential target audience for Guix, or is > it mainly focused on HPC (High-Performance Computing)? Developers is a pretty broad and generic term to start with. Considering Guix is somewhat of a general purpose package manager/Guix System a general purpose distribution, I think the better question to ask, instead of asking for target audiences, is, how and in what way Guix features and concepts can aid and help with hacking on software. HPC is an area where Guix can be put to good use, but it's also a reasoanble choice for other areas as well I'd argue. IMHO Guix has plenty of useful features that, in my opinion, can be put to good use in the process of developing software. I *mostly* work with C and Rust, as well as Perl, and less frequently, Python and CommonLisp; so my experience with Guix is mostly limited to these languages. Using a guix.scm file for projects to provide a good way to spin up a development environment fast/to onboard new people, and make use of guix shell (mostly with --container) while working on software; are probably my most used features in that regards. Best Regards, Wilko Meyer
Re: A Forum for Guix Users
Hi Sarthak, Sarthak Shah writes: > As of now, it's a bit difficult for beginners to find answers to their > problems in the mailing list or in IRC logs as > they aren't very easy to navigate compared to forum threads. I'm not sure wether having a web-based user forum solves this issue as it would be yet another place to look up a potential solution in. I'd also argue that a web-based forum doesn't provide anything mailing lists can't when it comes to the ability to have threaded discussions. In my opinion there are two things to potentially solve here: - discoverability of information across the various places where these could've been found (debbugs, mailing list archives, irc logs, docs); which more or less boils down to having better search options. - if there are questions that common that they usually get asked frequently/looked up frequently, that's usually an indicator to improve documentation on the topic. > It would also immensely help to have community discussions and other forms of > information concentrated in one > location instead of split over the IRC and the mailing list. This would most likely mean a split across three locations, IRC, mailing list and a potential forum, instead of just two then. Regards, Wilko Meyer
