From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id kGZDG7KCuWLTOwAAbAwnHQ (envelope-from ) for ; Mon, 27 Jun 2022 12:13:06 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id UA0jG7KCuWI6zAAA9RJhRA (envelope-from ) for ; Mon, 27 Jun 2022 12:13:06 +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 318552B470 for ; Mon, 27 Jun 2022 12:13:02 +0200 (CEST) Received: from localhost ([::1]:39184 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o5ljp-0001PB-B7 for larch@yhetil.org; Mon, 27 Jun 2022 06:13:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37684) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5lhC-0000Z6-0q for guix-devel@gnu.org; Mon, 27 Jun 2022 06:10:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34946) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5lh8-0002Pp-Oo; Mon, 27 Jun 2022 06:10:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=wX2+JbLNiSJxVHlA+DalWvHL8DcHqNmRAQjOrjDLOiM=; b=alWqsJaDTEor77KLTJyo 4r2fGnNNCojzXCiWfJEFp7sjrl9bdgc8uY6BzsBq14zLBs8f+OMzT4jY46XpOvFMFTxHOGI5bF6J/ 6BA2hbTrebCSC6MUE8FbTkOvCNyRgSYVqzk9XjztRcdZ+IvLgpGGxckAY7NpoZUalUNGFR7QRlyzf ZgniAWjQ2Lys9apsktqcwBFeIoi/OgReUpTSaMkoywivS47GR1cT6rcqBe4WX7UU+PqbgdhqT9qDk rV2e+EwegEWHFanx8vHz9YlEyjlZ0/4mqzokEfXJB+8XeQKuzs9m7TyGB81FXIFXQVaeChcnhLc0j swdSnWwvL/+zuw==; Received: from [2001:660:6102:320:e120:2c8f:8909:cdfe] (port=34242 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5lh8-0001Xb-BA; Mon, 27 Jun 2022 06:10:14 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Maxime Devos Cc: Tobias Kortkamp , guix-devel@gnu.org Subject: Dealing with upstream issues References: <6d31ff958ec0c75cbba8324a275315d195a54902.1653045472.git.tobias.kortkamp@gmail.com> <87sfntu6ft.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Nonidi 9 Messidor an 230 de la =?utf-8?Q?R=C3=A9volu?= =?utf-8?Q?tion=2C?= jour de l'Absinthe X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Mon, 27 Jun 2022 12:10:12 +0200 In-Reply-To: (Maxime Devos's message of "Fri, 24 Jun 2022 23:41:49 +0200") Message-ID: <87r13aifi3.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1656324782; 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=wX2+JbLNiSJxVHlA+DalWvHL8DcHqNmRAQjOrjDLOiM=; b=n5EME6rOFotWm2ulkkmSyKpRWZWQdcLtZ8tcdBVHqhZ9gDEKnZiPRkzbDu4IaJqqpZC+6a AzyPtfx1INDFg/CRgP5n4KkKKy2uyOc/7DqDqaNrZ7ZiQfdIL45X8hdACS0IT2o/tSp3R8 Gfd/mxSqI/yLUHd+80nnB5DUs/e+ypjsbzwb0C9Fx/Yzqe3x/oTeMSqoC6Gfb0HHTRzhDm 7OV+J3+QO/E6KLDPsfe+xXwzxfG8+1QuJSwhhvLUGFk1ttIGmDglhUZ3T4SpwLio9BNkPC Kaok+yGg/HaKLK6pNRYMraEYs+Aw5RSUGp2a3SocU4CYXdtqDUSo7Q0YqRbudg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1656324782; a=rsa-sha256; cv=none; b=oxZFSKlrhH7fYoIJMPxDStk8DUGYz82/3vXZWdXd0M9YcjYdu1QcAPolKqJoEGIlzqfx2W gDWUUDZDvxHne8u7kqpZgkFkPPcgJ78cuFX3pVZdBDU5e5yQLmFn7K7rdZkHuKTbvfsQxY tnaHs2hxWGgZyE1W8cJMt97LV2nonBuGvNH9jyTnkatrMVaB8welrH3ZaOI7ondTG1XUK2 TMhhrFW1zXwDSTdflxBxEH/yUD2gr35HpSWP1mjYoop9paUFDJnRmeSQ/GLah9pjI83Rbn K6g/xmMGGBP/VgaUbfDAcYNGyItcDcdLsbGiF75bnHnl0NSN2Yv05zhjO8fGeg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=alWqsJaD; dmarc=pass (policy=none) header.from=gnu.org; 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-Spam-Score: -9.45 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=alWqsJaD; dmarc=pass (policy=none) header.from=gnu.org; 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-Queue-Id: 318552B470 X-Spam-Score: -9.45 X-Migadu-Scanner: scn0.migadu.com X-TUID: ung04pckgdED Hi Maxime, (Moving to guix-devel; starting point at .) Maxime Devos skribis: >> That said, I think it=E2=80=99s a bit too much to ask of a downstream pa= ckager >> or user to address these issues.=C2=A0 As I see it, these issues should = be >> reported upstream and addressed upstream. >>=20 >> I hope that makes sense! > > AFAICT the issues have not been reported upstream yet, so I don't think > we can close this entry on debbugs yet. While I'd like for downstream > packaging to be trivial, the sad reality is that sometimes is not the > case, the issues are still there and need to be resolved somehow (fixed > downstream or upstream, or reported upstream). > > If not by the new downstream packager that submitted the patch, then by > the the one committing the patch, or by a reviewer, or by some more > neboluous role of a random Guix contributor, or in some exceptional > cases the issue could be considered =E2=80=98too difficult and not too ba= d=E2=80=99 > with some corresponding reasoning. (It's most efficient if the > reporting or fixing is done directly by the submitter, but if the > submitter can't do it for whatever reason, then surely something can > eventually be worked out by other people, albeit more slowly.) > > However, AFAICT, none of that has happened yet. > > More generally, I don't think we should have an =E2=80=98packages include= d in > Guix should be good, unless submitted by a newbie=E2=80=99 exception. Al= so, > potentially the new submitter would _like_ to learn more about Guix > (and have time for it, etc.) and learn how to improve things? > > In the future, if someone submits a patch and I notice it has some > complicated problems, should I just ignore the complicated problems and > just LGTM? This seems contrary to the concept of reviewing to me.=20 > (This is probably not what you meant, but to me, this is implied by > your response.) You did thorough review work and pointed at valid issues, thanks for doing that. Those issues are upstream issues, in that they=E2=80=99re not Guix-specific. For instance, that ./configure runs binaries effectively prevents cross-compilation, whether in Guix or not; that code potentially violates C99 strict-aliasing rules is also not Guix-specific. My view is that such issues should be reported upstream but cannot alone block package adoption in Guix. Regarding the review process, I think we should strive for a predictable process=E2=80=94not requesting work from the submitter beyond what they can expect. Submitters can be expected to follow the written rules=C2=B9 and perhaps a few more rules (for example, I don=E2=80=99t think we=E2=80=99ve = documented the fact that #:tests? #f is a last resort and should come with a comment). However, following that principle, we reviewers cannot reasonably ask for work beyond that. Upholding this principle makes sure submitters can have a good picture of what it will take for their work to be included. Related to that, I think it=E2=80=99s important to have a consistent review process. In other words, we should be equally demanding for all patches to avoid bad surprises or a feeling of double standard. I hope this clarifies my view! Thanks, Ludo=E2=80=99. =C2=B9 https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.ht= ml