From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id wN5SDgz8h2QSSQAASxT56A (envelope-from ) for ; Tue, 13 Jun 2023 07:18:04 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 0KViDgz8h2QOKAAAauVa8A (envelope-from ) for ; Tue, 13 Jun 2023 07:18:04 +0200 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 7C0883ABE4 for ; Tue, 13 Jun 2023 07:18:03 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q8j9z-0005Bg-20; Mon, 12 Jun 2023 11:08: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 1q8j9x-00057k-3i for guix-devel@gnu.org; Mon, 12 Jun 2023 11:08:45 -0400 Received: from cascadia.aikidev.net ([173.255.214.101]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q8j9u-00027N-P9 for guix-devel@gnu.org; Mon, 12 Jun 2023 11:08:44 -0400 Received: from localhost (unknown [IPv6:2600:3c01:e000:21:7:77:0:50]) (Authenticated sender: vagrant@cascadia.debian.net) by cascadia.aikidev.net (Postfix) with ESMTPSA id 211D51ABA6; Mon, 12 Jun 2023 08:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=debian.org; s=1.vagrant.user; t=1686582514; bh=HUGz2h4AaM99QxIslGCYnGyjTR3QeBOQvB1zVWebD14=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RcqqB/cPLgBnsNQ4h5vEaViWjKty7HxpXpIwPsX8uG0hrEFsmjinco76dW7y3ab1r 4g+yb8bj6BAhijD7x3rLizuRSHm2pB59n+JM6J8kAG6KmdcnZsBwFmFYvRcoDVLnSW 8EsTw2iW5+PmHWs4MmKTeovhn20Kum3R5V6IECNwygBGXnrHKVbJhQ9q/i/uZpy+l+ t3ziZWQPRrq5nLlbn6VFx2COrDizPn6ybHyKBtnDSqmHtyTIKgHZ67llX9dvfuSfJJ 8rdGnWFs4FUeDW+bVN8LZ3o//i97+yktoUl1/6L1eTNSK+QJ4d26cfF4wpWmjgA1nz sfIpWfVyN2D1w== From: Vagrant Cascadian To: Maxim Cournoyer , Maxime Devos Cc: Nicolas Graves , guix-devel@gnu.org Subject: Re: rust-build-system from antioxidant In-Reply-To: <87ttvd8ooc.fsf@gmail.com> References: <87v8g5g2t1.fsf@ngraves.fr> <281e598a-993f-e3f9-682c-4e14ff7a8522@telenet.be> <87ttvd8ooc.fsf@gmail.com> Date: Mon, 12 Jun 2023 08:08:28 -0700 Message-ID: <87y1kobtw3.fsf@wireframe> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: none client-ip=173.255.214.101; envelope-from=vagrant@debian.org; helo=cascadia.aikidev.net 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 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 ARC-Seal: i=1; s=key1; d=yhetil.org; t=1686633483; a=rsa-sha256; cv=none; b=T+5XCtByvsKZ1xeQvlTJ0FUw1MwMqIyBcFiTmRTfjmRq2p9mPUsINgzT+uFzEHDjzfcpPk DHuWtoujrZFNCgXvegB90hHqKQrKCDDDoCi9ttcr/iTMPlz8HgVfxC/45J7Hpg0jaJhkWD PybbG53YvbdMRvjY6tpyliNZe4LN23Xq2/wPB53m48CVtB0dvtZEOQRc04pwZ3awd7uhg3 hq1fqYT2KGtIlM6AJN970sk/MmwsuUjxYzkGCPY29giDojm+VJWxrouCo8LJurkH7L9LZ3 h5FbY7timNx8gT9GMkJgVJ+kEsTnHQpRWBtJCGPUVtumzUNS7KbYFgbQ2bzbtQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=debian.org header.s=1.vagrant.user header.b="RcqqB/cP"; dmarc=none; 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=1686633483; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=QtMeKhwdomk/o6p1DS0WpsSM066dETBlkpjxF3ZOP7Q=; b=RV5YoDBxn4kuqy/Zpmxq5Ykd02PjdKYmJjO+06WsI7rKoEphb6WzzvD1o68BI+VaL1pgW+ zH2obG1g/uEaHeuzvgfQvoeX0Ov5MjwhTsFrSluxNoHkAmnq/8zaaEiD72dMa/FCBnp4Nf vNGPDuuXpMUxRviyrzQL4KZ89SloIF1YT5vH/XtQbaNg7J+mIpfmO9uacj7B0gKwQOz3HB 3olnuyU7sQtc4rtEQtvHj4SPicC4c+CK8tN88udV1k/2QnJiBj3W2LrMngzul8wO/c31iO ikTev8bs5V6HbEqoOnIPJx3Omy+yCyuSgaDjTzijllKxWRFZd8mvOYVTMcjOLQ== Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=debian.org header.s=1.vagrant.user header.b="RcqqB/cP"; dmarc=none; 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" X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -10.13 X-Spam-Score: -10.13 X-Migadu-Queue-Id: 7C0883ABE4 X-TUID: hhpQYPmJgwWg --=-=-= Content-Type: text/plain On 2023-06-11, Maxim Cournoyer wrote: > Maxime Devos writes: >> Op 02-06-2023 om 20:02 schreef Nicolas Graves: >>> A few months ago, Maxime Devos worked on a new rust-build-system to >>> handle a few issues we were experiencing with cargo (see discussions on >>> antioxidant in guix-devel). >>> A month ago, we discussed about the possibility of the integration >>> in >>> core guix, and the required steps. Maxime and I had a different >>> approach. Maxime highlighted the possibility to make a smooth transition >>> but once that would require many gradual changes and deprecation. My >>> approach was that since we'll have to eventually migrate all packages to >>> rust-build-system, and since we can freeze all former rust packages in >>> an archive channel, I would be clearer to make the transition at once. >>> [...] >> >> Actually, I started out with the non-gradual approach, but that was >> overruled by Ludo', IIRC. > > Did you perhaps meant to say that it was disagreed with, or at worst > "blocked by"? There should not be a notion of 'overruling' in our > contribution processes (unless the Guix co-maintainers have to step in > as a last resort) if all participants strive to build consensus, as > mentioned in info '(guix) Commit Access': > > It is expected from all contributors, and even more so from committers, > to help build consensus and make decisions based on consensus. To learn > what consensus decision making means and understand its finer details, > you are encouraged to read > . > > I thought I knew what consensus meant myself, but the above link helped > me to re-frame a few things in a way that is more conducive to building > consensus. A possible reframing that might be relevent here too that is maybe not captured in the seedsforchange link referenced... In a consensus decision (formal or informal), it is often really valuable to not get caught up in "so-and-so is blocking X, Y, Z", but rather more "this issue so-and-so raised is blocking X, Y, Z" or even "this issue is blocking X, Y, Z". It is a perhaps subtle distinction, but an important one, as I think it can refocus on a problem-solving approach rather than finger-pointing-and-blaming approach. That said, I definitely get the impression the Guix community practices a very informal ad-hoc form of consensus, which ... while very flexible, misses many of the strongest benefits of consensus (notably, clarity of when a decision is actually reached and the next steps to move forward with it). A quick attempt at condensing a (more) formal consensus decision making process boils down to: * describe a situation, issue, proposal, etc. * clarify understanding of the above (this step unfortunately may get skipped as people are very eagre to...) * raise concerns * address concerns (as a distinct step from raising concerns) (iterate and repeat above steps as necessary) * call for a decision (all concerns ideally resolved or mostly so.. ?) * record decision (noting outstanding concerns if any) I am not suggesting that a more formal process is even appropriate to guix patch review... Obviously, with the asyncronous nature of, say, a mailing list discussion, these things do not necessarily happen in a structured sequential way, though possibly being aware of the "ideal" formal process, people can informally attempt to approximate it. I do want to point out that informal processes are more prone to falling into difficult patterns (e.g. defaulting to hierarchy or other power dynamics), at least with the social aspects... I think this is a collaborative project, so everything kind of has a social component! We all fall down sometimes or lapse into old habits now and then, but even if there is no formalized clarity of process, it is helpful to at least reach towards the spirit of consensus building... live well, vagrant --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZIc07AAKCRDcUY/If5cW qu2eAQDWe4qvxDBsTv15yl6qzc9bD2L/tAgShpPQHMT22DdjpAEAxNR3PtxaJDjJ jO0UC5sf1tT0eXSJcfbDwG+C/0ZiVw4= =gn9Q -----END PGP SIGNATURE----- --=-=-=--