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 ms8.migadu.com with LMTPS id KI8EJmgZwWXT8QAAe85BDQ:P1 (envelope-from ) for ; Mon, 05 Feb 2024 18:22:48 +0100 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 KI8EJmgZwWXT8QAAe85BDQ (envelope-from ) for ; Mon, 05 Feb 2024 18:22:48 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=bayesians.ca header.s=protonmail2 header.b="Tg/WvXYP"; 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=bayesians.ca ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1707153768; 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:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=G7QQwvwDMUHR0xVzn8N++V58Ur3QCxOrfieo6J8/QPw=; b=J/R7plNacGJzOR0lVInuxCpMUDCo/P4NGYShf3zrUi3rNx5nHZdXorexg+uAIqeZNta7Ni pktna/2yr2rZLMCRfH9OAs74vb3MaWtdGXgKH6zDVbRA5EF9PqMuM2e5H88AaVvySsg4fi owxRMOLMLz+BW/7+2htqQS2vNkeZVV/VBlWyTx5eApdqQR9nXUImqo2M6kmtTO5d1ZMOPQ dnqhfd5qCKptk9XR4vivIJPkLSkE4FJ4tH72S6IRt1qIcbUXuo4SmlNLD4qh0abM/mqum3 GZEC+smBAThIw27ow2xJClBwYpZgW9vmGbSTaBlLl0gOFr444+24a4NzyGJxRA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=bayesians.ca header.s=protonmail2 header.b="Tg/WvXYP"; 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=bayesians.ca ARC-Seal: i=1; s=key1; d=yhetil.org; t=1707153768; a=rsa-sha256; cv=none; b=aHPZ8PlGmuofyQFG0nf5zzzMOS1rmr/1eKMuicYL5n/8fes3U6VkkSX59we0Bk76a0GQM2 0sqJSS7EROFhUq9bQ1fQgS9MffXtOd6vOoJHeljPkLsc37TgFrORUbBi/UNXrfj2X99PXa u7yp9s0QuIU9rG2Ob1aoI0lnr4pVTvC5B0Y7wE/Q/mjUgqfiVN8q3j8cD1o1XmZyPuCZt+ phfX/wBYYDUrNdsgOHRoWuj9xBWZEumWeQvVv3SnIyJEe4hT7RHXA4+Vufe5okLqosuoT9 EOm3ZiABSYDjAuVyO4NOQNrX28Q+uEj5IHa8WcIte4T9zz44b+bLI3BiMUNd/A== 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 2F50677893 for ; Mon, 5 Feb 2024 18:22:47 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rX2fk-0007Nl-JQ; Mon, 05 Feb 2024 12:22:20 -0500 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 1rX2fi-0007Nd-Tk for guix-devel@gnu.org; Mon, 05 Feb 2024 12:22:18 -0500 Received: from mail-40136.proton.ch ([185.70.40.136]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rX2ff-0005YT-GD for guix-devel@gnu.org; Mon, 05 Feb 2024 12:22:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayesians.ca; s=protonmail2; t=1707153731; x=1707412931; bh=G7QQwvwDMUHR0xVzn8N++V58Ur3QCxOrfieo6J8/QPw=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=Tg/WvXYPjG0bC6vUiTdgtEA4fPBzOzU+UTInJGf/yrAsirNa4rKjsjnpcP8jn85hE SRpT/Ym5hJmID3C1bSoMXutGeBzrGb88borTf80VpkqdYOBIqBUy8wT4EaXl8bbzUI ynSzzgbnVA7awKcEZsQJy+Gx17O/0fgZsjViC3szd5MzppgK5TkTljmgzCAy/waUo5 QppSk2uTK4++BvE479jhCDKMXWWRyclR3Cnmml7gw5wZsl6aEbCh8DtrXimTcIWK/H oEKPbAtT8yQ1sy1aEbxbQvR+rC2F1PAYahDjJ/vrnNhu3ICYMMlO0elnQI6Yw3zHep NJ5jEs+nT22JA== Date: Mon, 05 Feb 2024 17:21:38 +0000 To: Tomas Volf <~@wolfsden.cz> From: Suhail Cc: Leo Famulari , Steve George , guix-devel@gnu.org Subject: Re: Guix Days: Patch flow discussion Message-ID: <87r0hqg735.fsf@> Feedback-ID: 38691229:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.136; envelope-from=suhail@bayesians.ca; helo=mail-40136.proton.ch X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 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, INVALID_MSGID=0.568, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.78 X-Migadu-Queue-Id: 2F50677893 X-Spam-Score: -6.78 X-Migadu-Scanner: mx11.migadu.com X-TUID: 1hwUb9oNRqoO Tomas Volf <~@wolfsden.cz> writes: > In ideal world, there would always be *some* reaction from the > project, even if that reaction would be "we do not want this change". Agreed. A reduction in the time between a patch (or patch revision) submission and a review/reaction would be a positive change in my opinion. > Even if it would be just an auto-close (for the "contributor can't > work effectively..." case). Are there current instances of "contributor can't work effectively"? If not, I propose that decisions concerning those situations be deferred till we have actual instances to guide us. > 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. Agreed. I believe the below steps would help with the current situation, and perhaps both should be pursued (among possibly others). 1. It would help to eliminate the need for review in certain kinds of patches. Some version upgrades for a package $foo where there exists no package $bar that depends on $foo may fall in this category. More generally, some "known to be safe with reasonable confidence" changes may be safe to be auto-committed without needing manual review. Recognizing such changes could be challenging, but we don't have to correctly label all such changes in order for this to be helpful. 2. It would help if it were easier for the community to be able to identify= the next steps, given a patch submission. It might help to (more?) clearly differentiate between the below states: - patch *needs review* (automatically set) - patch *needs revision* (set explicitly by the reviewer, say, by using a specific keyword in their email) - patch *needs followup review* (automatically set if there's a revised patch) - patch has a *satisfied reviewer* (set explicitly by the reviewer, say, by using a specific keyword in their email) --=20 Suhail