From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.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 AG+6EsaLHWf6+AAAqHPOHw:P1 (envelope-from ) for ; Sun, 27 Oct 2024 00:39:34 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id AG+6EsaLHWf6+AAAqHPOHw (envelope-from ) for ; Sun, 27 Oct 2024 02:39:34 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=elenq.tech header.s=soverin1 header.b=OPZjtcu1; 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=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1729989574; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature:autocrypt:autocrypt; bh=o+O9T2I1AQKheZVr2XQ/RELvhGzx/JO0lCGSmoGEfjE=; b=lkBUHqXGy+ZUvocMpR9vZCNFB8CNHM18cdoKAqm6iHyjfRB+SuZlAnst/JuOctoAmOjr9N PTRpXcMlZW3QEfZmPm90rbcqNYWsqw02Z6+F4BSRgCD0hN1g6UK7AJmYayRt4mU3f3HVSU xzchXrZygarTkDFVW748LnFSbjd3xwCc0jtPzXbs4tE4HMqE0QrG59wVLe3Owx5evxTv4k zXffDfuCniem2zzNRLQME6WpTCLhQ39IEK+KAhq8nXnt24JL3NA306ZdpBSiDf3FAJ9wAB qO9VSM2b1XpOH5X6mUIO1yc8R7rHSWWMM98VQdwOomzeaBg9rqrzOjxBd9CIUw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=elenq.tech header.s=soverin1 header.b=OPZjtcu1; 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=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1729989574; a=rsa-sha256; cv=none; b=KXwCN2xu6Cx3EpbLsB3z9dAfjVTXtZY8E1ppQhoTpNfICjSAo9bmJqg/lvFxFUUR4Ep9kv uv3Sp4UyuAeFjorQWnDUT17+jx3W2xo+ZLlIRPZsBSeHh26bjU5R4gu2gehw4maIDXP+N3 LZu9aLLWraAc59guwf71SuV612PSYDE74R58spvKUcqknjx1RZ+QfwnreyyDon8s3PxFzl H2aisYVJmphLFROPM2ByarK9Nc9OUFjWSzJ/vBzS/dR2QpsBIF4xUJJtp7n/8m2vuTl7hB oQaRDwQLgsrmoihsyD81srhYpj93ZS5aOiHIGauwE7Ww/hL7IiHOSz1aI0fg0g== 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 972C547346 for ; Sun, 27 Oct 2024 02:39:33 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t4rIt-0006Dy-8n; Sat, 26 Oct 2024 20:38:47 -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 1t4rIr-0006Da-FJ for guix-devel@gnu.org; Sat, 26 Oct 2024 20:38:45 -0400 Received: from dane.soverin.net ([185.233.34.31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t4rIo-00035y-B7; Sat, 26 Oct 2024 20:38:45 -0400 Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4Xbd1B1TWsz2xHT; Sun, 27 Oct 2024 00:38:38 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4Xbd193ryTzKY; Sun, 27 Oct 2024 00:38:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elenq.tech; s=soverin1; t=1729989517; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=o+O9T2I1AQKheZVr2XQ/RELvhGzx/JO0lCGSmoGEfjE=; b=OPZjtcu1qY5tQEcXqXaO5YEeVqxIzPp7rW9IaOLQq7j0rsxWrxXb1vjkzoEMnTQGmxDeP7 UcKAcznaCl+EvPXvwxl3W3NKFZiFHuNffnjkR16nqp78WJob+PTBib5ewpdClxKRYH12YE 4BWioooqOOuVOF+S3hEUxUXPhqZa9HFu8mJoXHHIE9lN14SfM10lk1SPZpzaBv7TNliPYM rIp/QVxjFAjW3qQv8dzpZjhqy1kVE3EcLgCVXKJXaQUc6M+p9scJY9XMG4ctoWXL8t2PDX P5/fRS+MBuAJbwHFjXXjQ9lRhLG489Iu1aiCOOCzsAAR/7SHw8h85492Ob6sIg== Message-ID: Date: Sun, 27 Oct 2024 02:38:36 +0200 MIME-Version: 1.0 Subject: Re: Guix (and Guile's) promise, and how to (hopefully) get there To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: Christine Lemmer-Webber , "Thompson, David" , guix-devel@gnu.org References: <6daee7b4-a5d6-4f80-bbfa-995e65e17ae0@elenq.tech> <87r083ht4p.fsf@dustycloud.org> <87ldyar4we.fsf@gnu.org> Content-Language: en-US, es-ES, eu From: Ekaitz Zarraga Autocrypt: addr=ekaitz@elenq.tech; keydata= xsFNBGViSyIBEADY3g71uW/0CVaVm5/ObqTicQXXJRuh1uafIFiUUZoAp1V3V89b3LZ/m0cL 8YNHxTxsx8sKIMYTGlOvARAMiSpDvkmpf5pLn5T7+VvK90FOv/Pkp1tNNT+tvd0m/7C58+39 s7tN+XppbjVRtFuSXY0aFe8rpivZsKxv+tPUHUnQQszXvwgx0GQl8AX99IE+j75NJmBHFVg2 0geKa7QVymu669ix2+zU8vGoOKf5nIS0qG1m/vrtwR3ZuuyWX9/E/uP95ahX5ETWtjhTDbEm MEaRperwbczBewkdERJ34vRrverqKQA1xHXoPsx4NkLMocORFSSCJsveXcgWlU+pUIOYcKUA ARJjHhoWoUH4LZt5EOb7U17AaYMmATUXPCqq8G3jEXq6i0O1J1obCJGIRG02R9GiGp4zrVuv 2hmyoAmed4xYZAtf9WjcbwiunDkMGIxscdSlfEH/9dt7PGdEvkZ0dNSCTbp4ctMI4jAfobAL LReMSGx1CgPi01J61a/n/SgR66AiRJZCyC1u2V7AK1rBOAYzOU4UoePz+yF1I7crjZWAQVo6 DlmmXW+29l/lh2oK5jOuNEcvI6qi+tPCYxpDhUhZeYgqFU+/xgGlMj/XGvwuIFlpVg9ovFMg 6mxskOCVP9xNEp/qHiHqByYu5NRcITo/z/3BUimdXTT4KSq2cQARAQABzSJFa2FpdHogWmFy cmFnYSA8ZWthaXR6QGVsZW5xLnRlY2g+wsGOBBMBCAA4FiEEg/pnRVjAUpRlfkwZt5lM+Jly CyYFAmViSyICGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQt5lM+JlyCybjZxAAy+YW 3Q22xKoMWJYw03qGCy87WPK+xGWDpKD6TJ77+/IEbldObyQRrKYTTGjQSy6WgaJ0txJMIqeK JyuWuR3bq+Vkh86Byntl25jknOJ+jY1zwPs6HnWFr+hS48FcQh/0D26h57Cqc+6nbKhJcva8 JsInbHTbWPz7wye+xhqY1LfdgVTbCyADESXdmBY30/vP4LzqW81atwYF6X7dN7ko/JvyPPdv VlcspmbP6zNihoApBHdMfJwYscyAsu6tTyL4hMG3zpraeU+S857vZN39gFagRng+uyZG7rfB dHHAFzT1LKOZ4dahavOfA0gS1RZTgtAGsvhUEBn9vKxlB4efZuKhwMtgQEskRFD6JIF1DYCj pLgn5x/y3oI6rn35R46VDhLfohcUWpvzplu6LBft8ZNr+UgoVYc6qBezyDlxk0FmhGI7DEoh gfUxljTALXjSdUGEw2mvp/Mcrz+ffemWpG4+Zq0UXR8sZaHpv+PqmFLFFSQCOCRTYbMKzZBn y03wym3y0tGtunDGm5pR7NEPqUO9QbZdKyTy4ftRkSfTpiPCF8+KKYDT8HimSrusmtTfR4R1 nBJ4lNBYgTdOyJYFbHdF0Jxo9r0t+K2e+6hX6bK79o6aC+/LtzkoYgjCWvAEopO0ras/XQYM S7/bCzeDIhXX5RqmMIp5XN+oBP2roZDOwU0EZWJLIgEQAMIgPDpJY9aOhFiFICx58XMM28An yUPdN39t0A8VkUbsvKXH6eNqUZj/Q3yNcZrknAT1vinv9FN/4uCUnsaqEKp+mRAYgzmNfeJk SWuMzmA04fcISIBz3sJUR0w/59tWi8QxlNn7IR6McAA3lHDXC+KYh9ZfhaOARfan1M6Ppy6g YltUQGSSPXU807inmQZh8GFTi8iUza7vGuBEnaNRGhmhR+blMwHSqVWN4gD81e8dSAEi3zNR sLoBXneHUqTcJMHvsT5cOk7cGMoVAWIffA2EKWfrgda57Qw+w+0OPqWEfKoXwnyt35Tl+Lxl 7MAaAG9R5760yhgkf3LmnBNP3m6StZ8Fv09Gdn5cGSbVnoofHDkg4PQDTD6aGz9af3SnGVg9 nb1Zm1XbqtnYwG9JvQhcjgWAHwrPLkHAcvKtfYWNe4wiirMjXMXxADY08g33SEchPJR2r4pg wttJS4kHUJ2IQUmSH/43RO5PkftWsCucYGeaG1aPr+GAkeKIS1M3OZGuqhd800mltpiH73eL XrUPF8fgngC+SGMrHXLfzuhaRxPNYUbsdF+wRkvjRSO4tCmSVpgfPsHu5emoZgix1iiTO7GF do7L6n1Ay3oF4Witoxc0Gcbu7ltYlZHGmDnsVTVALartsJV2muSXpWcjQiXyC0gUkIkUD/3P jtgVxK8xABEBAAHCwXYEGAEIACAWIQSD+mdFWMBSlGV+TBm3mUz4mXILJgUCZWJLIgIbDAAK CRC3mUz4mXILJrIaD/9CXGckwRCojuRzP0r6+8/RvNDc03CSe2W17WrSaoYgiRb+h5asI/AL yqw+QRgwXZpt0i9hNiDCe/baD62mufIyjKFjHoAWSYJuZ5VK3vWnro6GaxWULYt1+c4c4Lz2 d1nSK6j8F3CxYo7BFk6afOusjYfh+0HywThcYY+x+K5Z+4SdJejDLiL5AzJn2W5Gt/ViK5nI wl7uRQpayMc9zmI8ytUT2NJxovq1/fT9nB8VPwlbJTE9zvIqfqHh9o9Apx5o8yTaSCyGUyu9 8h/klqxFy4HAPJJu/3JkiMaCI45ZdCqRR1LIwhtmW2lb73r0rP/0S1cKi+ehA4oQvwiUw7zh XXw7mqzSAJ0SWT92Vy2G8Z8qqgwxwfQcdFZAyJAL1rgEPQljNT91Vgbc6DCUka2XW5BqyhEB eS0n1gK0hYXbM9FKegRsZxlmRAXa4KGXCwr4BNK6k+zkKPitezjbtcLgcKSHa8/HyHNkW7xH R+MN16x2elQPmQ2d0Ien1HgsK98+3prlUGwZIVCqa1ddSoW0llU3JzGsKrMAiYbWg/rOXFil RJbuhjflaLBVmfI8VlRQRocP+WEH0lsUWrtjVaGcBj1/YnIoT+zT6fPSXwPsrBvAWEjfl8HH e1F4cYb+ugPDwUTd1s2Uj2tF0/fhCHPy9sXyx/EIL3gqyBw9M2Rz9A== In-Reply-To: <87ldyar4we.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spampanel-Class: ham Received-SPF: pass client-ip=185.233.34.31; envelope-from=ekaitz@elenq.tech; helo=dane.soverin.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=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: -1.09 X-Spam-Score: -1.09 X-Migadu-Queue-Id: 972C547346 X-TUID: /Boyr3HitqPb So, On 2024-10-26 22:22, Ludovic Courtès wrote: > We have enough money, about 50k€ currently at the FSF plus a couple > thousand € at Guix Foundation⁰. So we rely on the FSF for the funding, mostly. I don't want to discuss if we want to separate ourselves from the FSF or not, but in the end, if we want to be independent we should control where is the money coming from. Can the FSF cut the funding? In any case, I think the money should be employed on keeping the substitutes, the CI and so on. That is important, because a great package manager that is unreliable easily becomes a poor package manager. Having a reliable Guix is good for everything. And many of us are developers, and don't like to do the reliability work. I could also think about the ramifications of the thing, the people who control the machines control everything and they might become evil and be too powerful. But it's a risk I think we should take. We have people that have been thanklessly doing this job for very long time, I don't expect them to become bad actors. If they didn't break after so long... I think they proved themselves. > > ⁰ There’s a ledger at > > but I don’t remember how to get the balance with the ‘ledger’ command. > :-) > >> - Is the Guix Foundation the way to do it? > > It is one way to do it, yes. Should we invest on making it **The Way**? >> - Does GNU, or the FSF, have some role on that? > > GNU isn’t a legal structure, it “doesn’t exist” so to speak. > > The FSF reimburses when we send them invoices; Guix Foundation can pay > services, hardware, etc. directly, which is more convenient. > > My preference would be to have a single structure, to improve legibility > and simplify things, and that structure would not be the FSF. I can agree with that. I don't dislike the FSF specially but I prefer to be more independent. What I do like is the principles we share with the FSF, and having a different financial structure should not change that. I think we all agree on the fact that Guix should continue to be a Free Software distribution. >> - Can we improve anything relieving weight from the shoulders of some >> people instead of putting even more on them? > > Yes! Committers can review code; people interested in governance can > help with the next steps, in particular the RFC process at > ; sysadmins/devops/hackers can help > with the infrastructure¹; and so on. > > These are some of the thankless tasks that are key to a healthy project > and where we must ensure a fair distribution of work to avoid burnout. I like that. > > ¹ https://lists.gnu.org/archive/html/guix-devel/2024-05/msg00183.html > That link is lost in the ML, shouldn't all that list be somewhere in the Guix manual so we can understand the whole picture of Guix? Maybe with an explanation about how these parts interact with each other? I think we should add something like that in "Contributing to Guix" part of the manual. >> - Would having more committers help relieve some of the weight? > > Only if they participate in code review. I'm not very good at it. But I'd like to help. >> - If so, should we propose commit access to people, instead of waiting >> them to propose themselves? > > We should. I think maintainers started doing it? Maybe we should do it more. > >> - Should we ease the process of becoming a committer? > > Do you think the process is difficult? Or intimidating maybe? Yes. I think it's intimidating because for some it's hard to take responsibility. I feel way more comfortable as an outsider. Also, I don't consider I deserve to be a committer or anything like that. I don't know how to deal with that. I approached you and told you I thought it was time for me to help, some of you agreed and when the process started to take long I preferred to let it cool down. I feel like I'm asking for too much. IDK. I think it would be more encouraging if it was proposed to people, and not the other way around. Making people ask for it may make them think twice and be cautious. Proposing them may make them feel encouraged and wiling to demonstrate they deserved the "price". I don't know. I don't like the process, that's for sure. But I don't know because of my personal case was weird or in general. I also saw some people saying their request was delayed and so on. The current process generates some awkwardness we could ease. > > Ludo’. In the end Ludovic, if I may: 0. Is the donate page in guix.gnu.org up to date? Maybe we should make sure it is, and maybe include the Guix Foundation? 1. Adopt an RFC process. I think it's valuable. 2. Decide if we want to invest on the Guix Foundation: - What is the status of it? Is it a fully functional organization? - Can we use the Guix Foundation for, for example, Tax exempt donations in the EU? And the US? Maybe some famous streamer could use their platform to make fundraisers for the Guix Foundation. (see what the Zig Software Foundation does) - Could we use the Guix Foundation to make a minimal Business (I hate that word) model to make a Guix-based product to get funds to improve Guix itself? Say, make a Guix hosting service? Currently most of us are throwing money to corporations for our small servers and would be happy to redirect that to something we love, while also having a great Guix based workflow. - Or maybe some of us could make that model and donate all or part of the profits to the Guix Foundation? (I think owning the hardware helps a lot) 3. Once we have money we can use, choose some people to maintain the infrastructure and pay them. - Can we really afford our machines? (are we paying for all of them? what are we going to do with the ones that are in a basement somewhere?) - Is Guix sustainable? 4. Maybe decide if we want to have paid maintainers/security-maintainers or committers (or teams!). 5. Relieve weight from people that have too much on their shoulders. I won't name names, but some of you are in the border to the burnout. - How could the rest of us mitigate that? Maybe it's time to speak and ask for help. 6. Propose more committers. Encourage committers to review patches, and also non-committers! (Steve, you are doing a valuable thing) 7. Add documentation about Guix's infrastructure to the Contributing section of the manual, so anyone can pay attention to that part of Guix too. I'll try to do that myself, if someone else is committed to commit it ;) Those points we could act on in the short/mid-term, or at least give us some direction. What do you think, am I missing something? Maybe some of the calls to action you don't like? Are they practical enough?