From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id AE/RFsIs0l8NBQAA0tVLHw (envelope-from ) for ; Thu, 10 Dec 2020 14:12:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id mASXEsIs0l/aFwAAB5/wlQ (envelope-from ) for ; Thu, 10 Dec 2020 14:12:18 +0000 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 0AA0A940355 for ; Thu, 10 Dec 2020 14:12:18 +0000 (UTC) Received: from localhost ([::1]:35018 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knMg4-0001aW-Sg for larch@yhetil.org; Thu, 10 Dec 2020 09:12:16 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43672) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knLqY-0006z5-4D for guix-patches@gnu.org; Thu, 10 Dec 2020 08:19:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:53936) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1knLqX-00014t-TA for guix-patches@gnu.org; Thu, 10 Dec 2020 08:19:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1knLqX-0003iM-Oz for guix-patches@gnu.org; Thu, 10 Dec 2020 08:19:01 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#40764] New package: r-restrserve Resent-From: Ricardo Wurmus Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 10 Dec 2020 13:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40764 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: To: zimoun Received: via spool by 40764-done@debbugs.gnu.org id=D40764.160760632014247 (code D ref 40764); Thu, 10 Dec 2020 13:19:01 +0000 Received: (at 40764-done) by debbugs.gnu.org; 10 Dec 2020 13:18:40 +0000 Received: from localhost ([127.0.0.1]:37249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knLqB-0003hj-RK for submit@debbugs.gnu.org; Thu, 10 Dec 2020 08:18:40 -0500 Received: from sender4-of-o50.zoho.com ([136.143.188.50]:21096) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knLq7-0003hX-GX for 40764-done@debbugs.gnu.org; Thu, 10 Dec 2020 08:18:37 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1607606312; cv=none; d=zohomail.com; s=zohoarc; b=FDEsmFyN4I/pvK7zdSVZ6i8mMBmbpIIDBXrFNiFzjx0oFAplhgVMGuNW8bkH8f53lHsQ85zebZy4z3rkUf0phaszAXll+QBYfue0wzCsRpT+cC4iiT5koD2/CjdPmiBVIDf+6/PBLTDEjV8mGp89BIyk8zVgx2FDp71QDwU59eM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1607606312; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=0wVFPtqWhe/Wk901B5OMQHy97S0RBtP1jEJGbBYFCNY=; b=fj9b6SJZnCZXMTKGcTUVBB89NQOaN5PcaeVjcIaFHmnke1CBOMHhWWRc8mdEIE0W2VAc+QV5JoX9wGdC+dM/rklW6it4TTzABZ8CXjDKzLgy4Hl7Eiziw86LWkwjLiy3/iAiHTZOK10ADATJ0Zqffsk8vh+vTCxMdIcFzYcJ924= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=elephly.net; spf=pass smtp.mailfrom=rekado@elephly.net; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1607606312; s=zoho; d=elephly.net; i=rekado@elephly.net; h=References:From:To:Cc:Subject:In-reply-to:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=0wVFPtqWhe/Wk901B5OMQHy97S0RBtP1jEJGbBYFCNY=; b=Qk6MJAShOS9pYTw5jtkAF6gNFu0giw8LKZPb+OtkwN23ZLPUHbMM4HWhAR4npojr CQrIEylpsExqLc3vghqKLokonfiwAHcgPhonLAGV2QXJKwNt5LKge9IU+YJt6axcZpi cF4m/ZH+q/ZQsgzu7MQod0a6AEID6HYMQWDoG3Fk= Received: from localhost (p54ad4df2.dip0.t-ipconnect.de [84.173.77.242]) by mx.zohomail.com with SMTPS id 1607606310510410.3270365987006; Thu, 10 Dec 2020 05:18:30 -0800 (PST) References: <87pnbzpyeq.fsf@ericcbrown.com> <87mtym4vri.fsf@cbaines.net> <864kktj0rx.fsf@gmail.com> User-agent: mu4e 1.4.13; emacs 27.1 From: Ricardo Wurmus In-reply-to: <864kktj0rx.fsf@gmail.com> X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Date: Thu, 10 Dec 2020 14:18:27 +0100 Message-ID: <87pn3hlrz0.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Eric Brown , 40764-done@debbugs.gnu.org Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: 0.70 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=elephly.net header.s=zoho header.b=Qk6MJASh; arc=reject (signature check failed: fail, {[1] = sig:zohomail.com:reject}); dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: 0AA0A940355 X-Spam-Score: 0.70 X-Migadu-Scanner: scn1.migadu.com X-TUID: qRH/Fjqu2vuH zimoun writes: > Hi Chris, > > On Wed, 09 Dec 2020 at 19:36, Christopher Baines wrote: > >> In the future, I'd strongly recommend not adding packages to the bottom >> of modules, unless you really want the package definition to be >> there. If every new definition gets added at the bottom, merge conflicts >> become very likely. Related to this, I also moved the package definition >> up off the bottom of the module. > > What do you mean? From my understanding, we always add new R packages > at the botton of the files cran.scm or bioconductor.scm; mainly. The problem is 100% with tooling. Git needs some context to apply patches. When you add package definitions to the bottom and that bottom context keeps changing you will always need to tell Git how to apply that patch. By picking an arbitrary location somewhere in the file you avoid this problem because it=E2=80=99s unlikely that other people will pick that very= same location. > The only fix to avoid boring conflicts is to reduce the time between the > submission and the merge, IMHO. Not even that would be a fix, because you can have two different people submitting patches for modifications at the bottom of the file at the same time. Applying them one after the other will result in the same problem, no matter how fast we are. Of course it=E2=80=99s always better to reduce time between submission and application. It would be *great* if we could find another way to appease git and do the right thing for the most common case of simply adding a package definition to the bottom of the file, no matter what context there might be right above. --=20 Ricardo