From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id MGHkICJtHWfe6QAAqHPOHw:P1 (envelope-from ) for ; Sat, 26 Oct 2024 22:28:50 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id MGHkICJtHWfe6QAAqHPOHw (envelope-from ) for ; Sun, 27 Oct 2024 00:28:50 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=libre.brussels header.s=mail header.b=dMeKygwb; dmarc=pass (policy=none) header.from=libre.brussels; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1729981730; a=rsa-sha256; cv=none; b=FOx7uL4ZCEq+LcUwpzoVxpdEkGyyaPRgpFj/I6YcJljAUKj1YXPDMXJvgdhDKJ0f1mGz0l eqN/AsZgukEVv7p14TwpDv6eiXKzz144zwR4PuYO5Px8bw1/14hbhZ2LjIrhKKTxLBEXs9 /eHtmyUg5T0+1PtsLiDJAhhl4XB4SuK7RtFi/I2GhAQJsfZL1VXNKqlOUADrXdXX5mLI2Y hXWlXx1IeXI4LvNIoaw/AuKw0lfFiBRapX1vWjyRmAbLyt0b9n7Zh+Q9HyOd79dBDf7f5k s/RpRSWOXR/xUQhWYstK2MI3xLewjLq3WyqQvP2T4WlBvJXnNkcRjG1lzvU9IA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=libre.brussels header.s=mail header.b=dMeKygwb; dmarc=pass (policy=none) header.from=libre.brussels; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1729981730; 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; bh=bB5y8ItpFqUWNPJWD25sfvgjsotGqCWNZV1gVfnF7Is=; b=e2A07Y2uYvSjU9cyHgcekOTD4mOlCIzLw/grEX9VJkyvqxlvVv3SRAICs0QZuLo0NJ9Wuu ZbWxqMB/M+3teuvT8p//FObtVgJGxtR0DyyYjEdNjclZNdsuQy6BZFDKC+kAyIZnZ9DMxe vRaI0rvfY5g4HUXBw4cwGyAnF6wKLrQyDvpaFaShtZv1X4TkYdoAO3w+qsVoSq5F2dNMaU +GIzFaUocX+0WYasmUKNXVZNa3hS1hTbuNgAZOy7MgAjVyyf67tfsJtQHcWec/Jv6XAQv0 3bvJOFHJmMm2HtMMQqkZUJvWmTEqy7gKTmlDekqfE2b7S8ZJ7c5XPfmyKDO0jg== 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 0EF2381509 for ; Sun, 27 Oct 2024 00:28:50 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t4pGb-0005wO-AQ; Sat, 26 Oct 2024 18:28:17 -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 1t4pGX-0005w6-N8 for guix-devel@gnu.org; Sat, 26 Oct 2024 18:28:13 -0400 Received: from libre.brussels ([144.76.234.112]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t4pGV-0004YL-HR for guix-devel@gnu.org; Sat, 26 Oct 2024 18:28:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=libre.brussels; s=mail; t=1729981685; 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; bh=bB5y8ItpFqUWNPJWD25sfvgjsotGqCWNZV1gVfnF7Is=; b=dMeKygwbqFlRYp+Ie9L0giVUdI84Njrv4yRpwiWP2kvi0u6WlZZEYDnsmCpCYfN5qrZJT/ dZ5uTNnX2JrROqYNRqkDDjFPhKh7Y1pkPIhgSXLcXP4O03yAI1mNrsEccRDxwERTxk+Jfb dSt1CnGj8Ej+S7M6/eCfh0gQWvF+eZk= MIME-Version: 1.0 Date: Sun, 27 Oct 2024 00:28:04 +0200 From: indieterminacy To: Suhail Singh Cc: Christine Lemmer-Webber , "Thompson, David" , Ekaitz Zarraga , guix-devel@gnu.org Subject: Re: Guix (and Guile's) promise, and how to (hopefully) get there In-Reply-To: <87plnm6cnj.fsf@gmail.com> References: <6daee7b4-a5d6-4f80-bbfa-995e65e17ae0@elenq.tech> <87r083ht4p.fsf@dustycloud.org> <87plnm6cnj.fsf@gmail.com> Message-ID: X-Sender: indieterminacy@libre.brussels Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=144.76.234.112; envelope-from=indieterminacy@libre.brussels; helo=libre.brussels 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_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-Spam-Score: -4.80 X-Spam-Score: -4.80 X-Migadu-Queue-Id: 0EF2381509 X-Migadu-Scanner: mx10.migadu.com X-TUID: 8zsn531eWDCB On 2024-10-26 18:40, Suhail Singh wrote: > Christine Lemmer-Webber writes: > > ... > > Specifically, the bulk of patch submissions in Guix deal with packages. > Barring some core packages, perhaps Guix would be better served by > splitting other packages into a separate channel. The organization and > management of said channel could be optimized for tracking upstream as > closely as possible. OpenSUSE's Factory model with OpenQA comes to > mind > [1]. > > #+begin_quote > The core of Factory is divided into two rings (0-Bootstrap, > 1-MinimalX). Ring 0 contains packages that form the most basic, > minimalist system that can compile itself. On top of that Ring 1 adds > what's in the default installation of the two primary Desktops. All > other packages are not part of a ring. > #+end_quote > Having explored the ecosystem of certain tools (what is a dependency of other dependencies), I have wondered about how this plays out in terms of governance (particularly priority or emphasis). For instance, many tools eventually have a requirement for Perl - given that eventually a supporting tool may provide a need for its regex or build qualities. Now, its quite likely that the version for Perl is not an inhibitor for other tooling to increment as versions. However, I do not know whether this (or similar tools) are articulated in a centralised and documented environment. (I do read references conversationally from this ML from time-to-time, especially when discussing packaging for specific languages - but such fleeting opinions are not necessarily the same as a dedicated resource with a uri to point to). Practically speaking, is it worth each team concretely highlighting 10 core tools to prioritise and maximise documentation and policy for? As well as 3 tools which their circle creates, that are important for other tools in other team circles? Such a procedure may allow more of a tracking over time of changes of priority, as well as a better attempt at gauging how such priorities are being treated. > Orthogonally, the project would IMO also benefit by having automated > testing to ensure that the combination of packages work well together. > > As things stand today, the incentives for those without commit access > are such that it makes better sense for them to focus on their own > channels. This is a shame. On the topic of cloud/service type activities, Im still intrigued by the allure of Guix wrt forge services. While I understand Arun Isaac may have other/greater priorities than to focus entirely on his guix-forge project, I have wondered about having Guix/Guile being considered a column in the code forge domain: https://git.systemreboot.net/guix-forge/about/ After all, if something can be configured once in Guix it can be spun up, and reproduced in a sustainable and functional way -- this should be a point of distinction for this community. If enough hackers control the form of how code is stored and transmitted then many points of concern could melt away. Positions such regarding centralisation or decentralisation of package definitions or regarding (Neo) AI would reconfigure if Guix had more sway over forges. JM