From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id WOH7JPdnHWcDGAAAe85BDQ:P1 (envelope-from ) for ; Sat, 26 Oct 2024 22:06:47 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id WOH7JPdnHWcDGAAAe85BDQ (envelope-from ) for ; Sun, 27 Oct 2024 00:06:47 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=incana.org header.s=key1 header.b=YmE33d2H; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=quarantine) header.from=incana.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1729980407; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=8UK/RJ7oAEz+AHS6+U/yemyP47092E+vS8rt5qWCZec=; b=oxestuICBu9jweTS4iUbSI4/XJKrfNDit4/M+kgtY1hWJFT29XoSkgrss9kA6gDkk5s+du gXbz6ScdYFRhMn/Zucu2WXa7j3VibLlW4qKqs0xrMDLLW85/1P0qcEHXaopSCZaLy0qub9 tAy2BFf4SYg1zsuC2s7ztgVf6xyYd0F8v4aS8ZWUxBaHl72vJSzzGFRL5Oj4twA1NP1g7d XeaNsKFcUKqThbGIKXydfw5m9y2t8JnmTBNfpnNNu103oLQySQ1ZjZZBIRotW+VUAxfbvp lu6fNQkqoNTkNIrF2KHLY4eFniRWVnc3kP2JGr+GAkGS734xpWGwLQPdwoxHFg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=incana.org header.s=key1 header.b=YmE33d2H; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=quarantine) header.from=incana.org ARC-Seal: i=1; s=key1; d=yhetil.org; t=1729980407; a=rsa-sha256; cv=none; b=OlU7wVLQDC8Noun/Gs1o/85h+3To4+8H3kR6KPPTkj8Nr9v7rsFipedv+40+/ebw8+Ef1O zdkFeGLYk801jlgLNMtilCYcSTUsi9mkK0PzIqJ9iEFLBWF8waUVJ/oMhDO9K7RV630vRe bazuftunsKfiodz5brVGFL0lGqv1hu8fmXsd1OdStKyeMGOJLOXpzumEZSoEUGw2/DuS/0 1Fw2s3TiM5txVNftqrF9N1ZD0Eqyyws1qF2j+g9n/CcZgk9vQj11a1KdOV5r0B+Ys2btFl AKqDIxpD2b3KUEVnvgJAieJmPfOnqvHrJTPk/4I7JXK4gI5YGdS8uC4BAS2+dQ== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 2F17044425 for ; Sun, 27 Oct 2024 00:06:45 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t4ovK-0003Pi-Eb; Sat, 26 Oct 2024 18:06:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t4ovG-0003PQ-TL for guix-devel@gnu.org; Sat, 26 Oct 2024 18:06:16 -0400 Received: from out-181.mta1.migadu.com ([95.215.58.181]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t4ovD-0000as-LI for guix-devel@gnu.org; Sat, 26 Oct 2024 18:06:14 -0400 Date: Sat, 26 Oct 2024 18:02:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=incana.org; s=key1; t=1729980365; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=8UK/RJ7oAEz+AHS6+U/yemyP47092E+vS8rt5qWCZec=; b=YmE33d2H5Z5xLRqwxqfKMYUsx3+Afk+dHYUnKD1K4XTjnvTcoYopzjaQ7LaKmLOpPknWFH SNHJB/eBLH5wSh+w3J8gkgG80y13gWYjJaFeavdzmesIArheCTkXHkRgHUudgYA9Lybh+a 18kmpk7V/GpZ0NK94bsyOm/26qvbrsqn9A+RibBcFswZOvx7UuY2ox6o2xzvw6qdSgtrlX F9glTpJekiZMpdnkv5yV3Zk6UU0/b1GXw2uUvhuMhoJwbKhTtu97eMQ7FZ9T6Y0g7FAw3a GUPsHqqiR4C+whEzOWlBTBC/lUDflyjsm9twyH0s7Q3HQBrP43oDp/8MEc7WTw== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Juliana Sims Subject: Re: Guix (and Guile's) promise, and how to (hopefully) get there To: ekaitz@elenq.tech Cc: guix-devel@gnu.org, suhailsingh247@gmail.com Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Received-SPF: pass client-ip=95.215.58.181; envelope-from=juli@incana.org; helo=out-181.mta1.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx11.migadu.com X-Migadu-Spam-Score: 0.30 X-Spam-Score: 0.30 X-Migadu-Queue-Id: 2F17044425 X-TUID: DgAE8afyJ+xq Hey y'all, Ekaitz, thank you for opening this thread. RIP your inbox. I think this thread demonstrates in itself one of our biggest issues. A few folks have mentioned it indirectly. I'll be direct. We can't stay on topic. So once again, Ekaitz, thank you for clarifying what this discussion is supposed to be about. In the context of consensus decision-making, this is part of what's called facilitation, and it's absolutely vital if we want to use a consensus decision-making model for governance. I think we absolutely can do that if we just use the tools others have built for making consensus work -- like the idea of facilitators. But I digress. After that preface, I'm going to respond specifically to the points Ekaitz highlights as the topic of this thread. > - Do we need independent funding so we can pay for our machines and maintenance? I don't know the details of cost and source off the top of my head (they were recently summarized in another thread), but my instincts are screaming, "Yes!" I'll return again to this later, but we should be paying people to do systems administration work because systems administration is boring and tiring after a while. Above all, no single individual should have to carry the weight of paying for our servers. > - Is the Guix Foundation the way to do it? Again, I don't know enough to say with certainty, though most likely. Because... > - Does GNU, or the FSF, have some role on that? ...Guix should break with GNU and the FSF. Moreso the FSF, but the two are irrevocably intertwined in the public conscious -- which is the primary reason Guix needs to break away. To avoid relitigating what has been litigated more than sufficiently already, the FSF made a bad political move that has destroyed its social capital and, as a side-effect, its financial capital as well. Even if it can help us with funding, it shouldn't. (More on why in a bit.) In terms of extant infrastructural support, from what I can tell, the FSF gives us hosting for a simple website, an ancient git forge, and mailing lists. While I can't speak to mailing lists, I can speak to websites and git forges. Given the incredible complexity of our existing CI and QA infrastructure, putting up some HTML and having a gitolite service running on a machine are comparatively no effort. I suspect the mailing list -- after migration -- would be the same, though I reiterate my ignorance here. To forestall misunderstanding, I absolutely do *not* mean that Guix should compromise on free software. Guix's greatest strength is that it is an uncompromisingly idealistic and principled project. If we change anything about our stance on non-free software, it should be that we add a single sentence to the manual informing people about the well-known and well-supported channel providing non-free firmware, followed immediately by a disclaimer that we neither endorse nor support non-free software, and that's *all*. Official Guix channels should never knowingly ship non-free software, nor should we ourselves provide instructions on installing, configuring, or using non-free software itself -- we should just point people to the place that does. Why, though, should we go through the effort of migrating our mailing lists, domains, etc. just because it won't add *that much* more work? This is a big and important question. The short answer is, the FSF is radioactive, and we're getting sick from it. Let me be frank. I promote the heck out of Guix. I've shilled Guix to more people than I can count, from professional systems administrators at internationally-acclaimed universities to hobbiest hackers in the most obscure corners of the internet, and everywhere in-between, all of whom are incredibly capable, knowledgeable, passionate programmers, and some dozens of whom are free software hackers. The main turn-off people cite to me is our association with GNU. As a particularly poignant case study, in conversations with someone who has contributed significantly to Guix on my recommendation and did not stay around, the primary complaint was not the email-based workflow (which was noted as unusual but not overwhelming), but that the GNU affiliation *makes them feel uncomfortable in our community*. They haven't told me of negative interactions with members of the Guix community; the GNU affiliation alone was enough. If we recognize that there is not enough growth in effort going into the project, we should address the primary reason we're not getting new people to bring more effort: GNU. > - Can we improve anything relieving weight from the shoulders of some people instead of putting even more on them? I think so. As I noted above, if we break with GNU, I am highly confident we will see an uptick in new contributors, at least some of whom can help there. In the longer-term, we absolutely need to pay more people to do systems administration for the Guix project. If we start paying people, those are the people we should pay first. Our patch throughput doesn't matter if we don't have servers to distribute those patches to users. > - Would having more committers help relieve some of the weight? Perhaps? This could allow more experienced contributors to focus on less-supported areas (sysadmin, for example) and help the overallow distribution of labor as a result. The issue is less the number of committers than the number of *commits* by relation to the patch backlog. To that end, any changes related to committers should focus on increasing patch throughput. In particular, we should focus on adding contributors who want and are able to help with specifically patch review. Indeed, my inability to commit (pun not intended) to patch review is the only reason I haven't put myself forward for commit. (Though I am working towards giving myself the time for patch review in the near-ish future.) > - If so, should we propose commit access to people, instead of waiting them to propose themselves? Yes, and, to reiterate, we should prioritize committers who want to focus on patch review. This doesn't mean we *only* grant commit to people who want to review patches, but there should be a clear expectation of patch review for any new committers. Committers who see someone consistently providing good patches and/or review should be able to propose that person to the other committers. > - Should we ease the process of becoming a committer? No, with one exception. If the committers discuss among themselves and feel that someone is making consistently helpful, quality contributions to Guix, but they haven't contributed 50 patches yet, they should be allowed to offer that person commit. For self nomination, nothing should change. Guix should not compromise on its ideals. We need people with a demonstrated dedication to those ideals screening others for the same dedication before entrusting them with material power in the project. Our current process seems well-suited for this end. That's all I have to say at the moment. As a final note, I want to highlight the amazing work from Arun Isaac and Chris Baines. While I know y'all have been working hard on Guix for a long time, I've paid the most attention to y'all's work this year, and from what I've seen, y'all have been kicking ass. You've made it so that the contributor workflow is not a meaningful point of weakness anymore. Thank you both. Best, Juli