From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 4O/+Nf9vzWOCfQAAbAwnHQ (envelope-from ) for ; Sun, 22 Jan 2023 18:18:56 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id QHkqNf9vzWP3XgAAG6o9tA (envelope-from ) for ; Sun, 22 Jan 2023 18:18:55 +0100 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 A43663F754 for ; Sun, 22 Jan 2023 18:18:55 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJdzH-0008Un-MD; Sun, 22 Jan 2023 12:18:35 -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 1pJdzF-0008UX-Ko for guix-devel@gnu.org; Sun, 22 Jan 2023 12:18:33 -0500 Received: from hera.aquilenet.fr ([2a0c:e300::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJdzD-0007px-Oc for guix-devel@gnu.org; Sun, 22 Jan 2023 12:18:33 -0500 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id E3B34AD5; Sun, 22 Jan 2023 18:18:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at hera.aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ8u-m2OZBKC; Sun, 22 Jan 2023 18:18:26 +0100 (CET) Received: from jurong (unknown [IPv6:2001:861:c4:f2f0::c64]) by hera.aquilenet.fr (Postfix) with ESMTPSA id F2F13239; Sun, 22 Jan 2023 18:18:25 +0100 (CET) Date: Sun, 22 Jan 2023 18:18:24 +0100 From: Andreas Enge To: Christopher Baines Cc: guix-devel@gnu.org Subject: Re: Proposed changes to the commit policy (#59513) Message-ID: References: <87cz8no0a0.fsf@cbaines.net> <874jsq40cj.fsf@cbaines.net> <87k01k2ef5.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k01k2ef5.fsf@cbaines.net> Received-SPF: pass client-ip=2a0c:e300::1; envelope-from=andreas@enge.fr; helo=hera.aquilenet.fr X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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 ARC-Seal: i=1; s=key1; d=yhetil.org; t=1674407935; a=rsa-sha256; cv=none; b=bTShQiNYSQ2hgjCKBUhGQvprLg+Deq9im3pPyVs451gn0sievOorrnoQBZzSj788xrZ9ve 5juDXwSeUMkRJTUK5UQFuQmWUDnBV5LbatavA14HYSx3/QywmW5FFAFz4Ga2iyPiCVJWX7 ZsuHwkqJ37sZgUyGqGDqO+LCl3kz/CKWYB4H6F6JTakL2dgQmXOJs3DvmzX8QlG17vSQif P+XDdw/LBTEE1UM046ykqNCUeNl93hvJJuIADJRpwniUjSAb5RjrnkCcDw9cC1NG0UxZZ4 5ShJKkp8gbUFqnRH91xsVlAQ83za7pkX0np4KdeuDz4F7PyNLUrYJnThUuGr4Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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=1674407935; 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; bh=Y6z89qzYP2mD5/XBj41pZ3O7fbSWsZ3NwaofxlnVuR4=; b=CcwFhlea14cwLh1Jc6qVEdYAZ5GCQ6ZK6N1vjNjOrNd/+N4AfZX2WQ3z5dE6lY0g/YVXpp KFM8Hlaq4UoF3GLZQ8CsKvcp1bLy31MOy2SjG8RlImCFdOxmSqMfqFZZQ1OyOwum9iKE1s UhcPo8Pn4O6KRvQs9V+99otOJH6wrsdOCZLwfu3wh05lgIsRK14Uz7X5jtLgbdzi8r5u9C Q9rBHAqQQJRtvU2aT1Dy+rk/+TuSHJyikDhFppQSF6Km/V53Od+qsyi492znZRux33TnxJ MmL6xPEYGHWnvwzz0Dn/FwP7UqB6vwMW7jP3iil0E9mlzrg12Yw8dxhoRHqaCw== X-Spam-Score: -1.39 X-Migadu-Queue-Id: A43663F754 Authentication-Results: aspmx1.migadu.com; dkim=none; 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: -1.39 X-TUID: BQlSe55tAMgB Am Wed, Jan 18, 2023 at 11:45:20AM +0000 schrieb Christopher Baines: > > as a quick concrete question: Do simple package updates still count as > > trivial, or do they need to go through the patches mailing list? > My feeling on this is that "simple" package updates are often not > trivial, or at least doing rigorous testing for these updates isn't > trivial. A definition of trivial might be "having little value or > importance", and I don't think that's generally the case for version > updates, they're often a valuable and important change. So I tried it once, and find the hassle offputting. It feels like doubling the effort - after doing the real work, I need to get back to it a week later and more or less go through the motions again (rebase the commit and resign it, recompile Guix, build the package again just in case), plus the debbugs effort. So expect even less package updates from my part in the future... These were the kind of instant gratification actions one could do more or less in the background, and they have become more complex administrative endeavours with delayed gratification. (I also do not know how to set up git-sendmail with my remote SMTP server login and password, but this is a one-time cost of learning which does not matter that much.) > > In case the answer is that submitting to the patch tracker is required, > > I would suggest to shorten the waiting period from one week to zero > > (meaning that it is okay to push when there are no problems detected by qa, > > without having to wait for human review that has no reason to occur). > That seems reasonable to me, at least in the case of package > updates. Given that's such a common change, maybe that needs handling > specifically in the commit policy. It would be nice to add this, yes. Am Wed, Jan 18, 2023 at 04:54:58PM +0000 schrieb Kaelyn: > On a side note, I'd recently discovered the flag to pass. To have a subject prefix like "[PATCH core-updates]" (as mentioned in the manual for staging and core-updates patches) instead of the default "[PATCH]", one can pass "--subject-prefix="PATCH core-updates" to git format-patch. This sounds like it could be a useful addition to the QA process. Andreas