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 ms5.migadu.com with LMTPS id eAN6LRKQvWIfcQEAbAwnHQ (envelope-from ) for ; Thu, 30 Jun 2022 13:59:14 +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 kF4CLRKQvWIhcAEAauVa8A (envelope-from ) for ; Thu, 30 Jun 2022 13:59:14 +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 8DA138430 for ; Thu, 30 Jun 2022 13:59:14 +0200 (CEST) Received: from localhost ([::1]:46380 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o6spF-0000pH-Q0 for larch@yhetil.org; Thu, 30 Jun 2022 07:59:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43828) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6sjm-0001rv-BC for guix-devel@gnu.org; Thu, 30 Jun 2022 07:53:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47752) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6sjl-0002wB-9n; Thu, 30 Jun 2022 07:53:33 -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=mYQO4Kj3qyA66zj7j+puNLlpSujn/YKfnL7xOcbt5Gw=; b=H9bD2ssUeZLv+2bryNqp H6OWs9ShcBUxZ2W7xEtAQKWYBZ/UYHdwu+1ZeiCxEzLWgAsAaWA6roFMyyKRIey9pivEaS/zzGAvA 5Ev6iZOiLqGg4vyRUfo5gCLgCz43NBjUKTUVuBH1ILkFntMrXa/SnlXAhn4Nr23dsxP05FloNbqwf meqERokijcauwXfah6ENXEWwbkTOrfzHyBOBqAPpFRQcKHWNlnZ7aIo476vu4rUKi3KjGPx7Xj44w qTMiyJi0iB+fgpXpCUtIuBp4p48S1ORr1StVZr5qbXvoaeEEtrku7JRHuExek2otTMiEa5khz8aCe zPkyjlEmP7+9sg==; Received: from [193.50.110.235] (port=37544 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6sjk-0002BI-Lm; Thu, 30 Jun 2022 07:53:33 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Maxime Devos Cc: Tobias Kortkamp , guix-devel@gnu.org Subject: Re: Dealing with upstream issues References: <6d31ff958ec0c75cbba8324a275315d195a54902.1653045472.git.tobias.kortkamp@gmail.com> <87sfntu6ft.fsf@gnu.org> <87r13aifi3.fsf_-_@gnu.org> <6d2b1052b3e63a67c42c4e6ce431b3f1bb4b4605.camel@telenet.be> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Duodi 12 Messidor an 230 de la =?utf-8?Q?R=C3=A9volu?= =?utf-8?Q?tion=2C?= jour de l'Artichaut 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: Thu, 30 Jun 2022 13:53:30 +0200 In-Reply-To: <6d2b1052b3e63a67c42c4e6ce431b3f1bb4b4605.camel@telenet.be> (Maxime Devos's message of "Mon, 27 Jun 2022 12:30:48 +0200") Message-ID: <87sfnm74g5.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=1656590354; 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=mYQO4Kj3qyA66zj7j+puNLlpSujn/YKfnL7xOcbt5Gw=; b=CQQF2VlEDmcvJjdwjc723+Qi9bE1hK3H5YDUeQ6h6CnKEyVTre5pw4hgOlTWzXRXCzDv8v dzpV7tiZTRiN6NqpblFOfi4rt8N6R5Sp/LgTJPtG77OH/aHuekIgx4Fwwmj2zN/n8mKGXZ XTrnwyDtJGoJ/fic0a5QRQOTxrMEeQOO4z4dP/tw36sIAhVNROWmz1AnyebIDvsuFmktJQ 42CSF3j7HAlV1b3saAkJdaTKuu0+14I3fUz5pMIXdxJruM1Fp0pGeguZrjxOr4I4mnaLEU 7+29ufGoCTS/ZrwNydiBj5QFIoUshuqwV+5Fd+y+RbZxEKbOBTdOwR0+y0HbhQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1656590354; a=rsa-sha256; cv=none; b=qgMiCa5wwJEeaL53SM0JlATpt03eKm44DNJfTy1x/1m7WcE7ri9dHnL34s5kuOnHGyLDXK fc+WcwSLQU7s3kVYOfWyuBxcT2qSx4oXdvlxMU4W7vdl8y/0JxLtdnnPZy8sT3+i8b1PfU fWQwQxM5/aATcIiDGKqRC+mPVzbKKHZq6C4+WbhkvDQ/DsJH2S4Cazty34dgOunNH/5hUa vaC3g15Q4OlYzNdAiHgppxe663L9Q5/zNYCWDFRkxai11O0Qq54JbOTplNOZ+/qwfYn7C1 pCMtBWemnsdN9OC2bGUBOG4SbHLghQV7Vd1B26A24eCY6JQTohRNBkNzoviuTw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=H9bD2ssU; 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: -8.25 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=H9bD2ssU; 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: 8DA138430 X-Spam-Score: -8.25 X-Migadu-Scanner: scn0.migadu.com X-TUID: zoS5SIVEs8dH Hi! Just to be clear, I started this thread as discussion on the kind of interaction we reviewers should offer to submitters. I am not suggesting changes in our =E2=80=9Cquality standards=E2=80=9D, nor am I sug= gesting that one group of people do more work. Maxime Devos skribis: > Ludovic Court=C3=A8s schreef op ma 27-06-2022 om 12:10 [+0200]: >> 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.=C2=A0 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=99= ve documented >> the fact that #:tests? #f is a last resort and should come with a >> comment).=C2=A0 >>=20 >> However, following that principle, we reviewers cannot >> reasonably ask for work beyond that. [...] > > We can ask to do send the notice upstream, if it's in the rules (I > consider this to be part of the unwritten rules). Yes, that=E2=80=99s a reasonable thing to ask for. However, we can only as= k for it if the submitter identified a problem themselves; if I=E2=80=99m the one finding a problem, it=E2=80=99s inappropriate to ask someone else to report= it on my behalf. > And I don't often have time for addressing the noticed issues and I > have other things to do as well -- I usually limit myself to just > reviewing. I do not intend to take up work beyond that. Of course, and I don=E2=80=99t mean reviewers should do more work! I think= the few people that dedicate time to patch review already have more than enough on their plate; the last thing I=E2=80=99d want is to put more press= ure on them. We have to care for one another, and that starts by making sure none of us feels a pressure to always do more. > I also consider them to not be rules as in =E2=80=98if they are followed,= it > WILL be accepted=E2=80=99 but more guidelines like =E2=80=98these things = are important, > they usually need to be followed, but it's not exhaustive, at times it > might be discovered the list is incomplete=E2=80=99. Agreed. > I don't think that patch submitters can reasonably expect reviewers to > do all the work. Agreed. > Also, previously in discussions about the review process, weren't there > points about a reviewer not having to do everything all at once, they > could choose to review parts they know how to review and have time for > and leave the rest for others? I don=E2=80=99t remember discussions along these lines. I think it can be helpful sometimes, and tricky other times. For example, for a package, I find it hard to split review work. But for a patch series that touches many different things (documentation, build system, importer, whatever), splitting review work among different people may work better. >> Related to that, I think it=E2=80=99s important to have a consistent rev= iew >> process. In other words, we should be equally demanding for all >> patches to avoid bad surprises or a feeling of double standard. > > I think I've been consistent in asking to inform upstream of the issues > (*), with no distinction of whether it's a new submitter or an > established one or whatever. I think our standards should be the same whether the submitter is a newcomer or not. The difference is in how we reviewers reply. To a newcomer, reviewers should IMO do the =E2=80=9Clast kilometer=E2=80=9D themselves on behalf of = submitters: tweaking the commit log, synopsis/description, indentation, that kind of thing. It=E2=80=99s important because that gives submitters a good experie= nce, it helps them learn, and it=E2=80=99s also low-friction for the reviewer. (That=E2=80=99s also the whole point of guix-mentors.) Naturally, one can be more demanding of seasoned contributors, and I think it=E2=80=99s OK to leave it up to them to fix such things. Thanks, Ludo=E2=80=99. PS: Sorry for the wall of text!