From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 yKxbJf04o2KLTgAAbAwnHQ (envelope-from ) for ; Fri, 10 Jun 2022 14:28:45 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id eAxqJf04o2LSuQAA9RJhRA (envelope-from ) for ; Fri, 10 Jun 2022 14:28:45 +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 44393F7C9 for ; Fri, 10 Jun 2022 14:28:45 +0200 (CEST) Received: from localhost ([::1]:42610 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nzdkq-00059I-2k for larch@yhetil.org; Fri, 10 Jun 2022 08:28:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50238) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzdk3-00059A-Nc for guix-devel@gnu.org; Fri, 10 Jun 2022 08:27:55 -0400 Received: from ns13.heimat.it ([46.4.214.66]:44292) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nzdk1-0005eM-Pm; Fri, 10 Jun 2022 08:27:55 -0400 Received: from localhost (ip6-localhost [127.0.0.1]) by ns13.heimat.it (Postfix) with ESMTP id 6E4DE30022D; Fri, 10 Jun 2022 12:27:49 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at ns13.heimat.it Received: from ns13.heimat.it ([127.0.0.1]) by localhost (ns13.heimat.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eBmw9mKzAyl; Fri, 10 Jun 2022 12:27:46 +0000 (UTC) Received: from bourrache.mug.xelera.it (unknown [93.56.171.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ns13.heimat.it (Postfix) with ESMTPSA id 69CA130022C; Fri, 10 Jun 2022 12:27:46 +0000 (UTC) Received: from roquette.mug.biscuolo.net (roquette [10.38.2.14]) by bourrache.mug.xelera.it (Postfix) with SMTP id AE9AE1B79191; Fri, 10 Jun 2022 14:27:45 +0200 (CEST) Received: (nullmailer pid 24068 invoked by uid 1000); Fri, 10 Jun 2022 12:27:45 -0000 From: Giovanni Biscuolo To: Arun Isaac , Guix Devel Cc: GNU Guix maintainers Subject: Re: On commit access, patch review, and remaining healthy In-Reply-To: <87bkv1lipm.fsf@systemreboot.net> Organization: Xelera.eu References: <87ee07m77w.fsf@gnu.org> <877d5um1oe.fsf@systemreboot.net> <87tu8viix0.fsf@xelera.eu> <87bkv1lipm.fsf@systemreboot.net> Date: Fri, 10 Jun 2022 14:27:44 +0200 Message-ID: <87o7z0itz3.fsf@xelera.eu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=46.4.214.66; envelope-from=g@xelera.eu; helo=ns13.heimat.it 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_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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" 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=1654864125; 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=ieuQKq+KFsd5etUbQsHEiLQpy4ZyopgOZEoWgkUbhfw=; b=FV7wVdGIBwzYDpjjucdlENZ5YU2F6bLkagR2Jn+QZKd77yBf+aF/9cpisEgDbFYqXIHago lMh5+BPbZAZSoizID08T90p07xp2k52/Q6ElPGkHiqzAvMDkgnmdPSF4W1XmWy9Db9anTc 0Pz+T+4ABe/9qAkyFS8vXpf0utoHyLpIPT7fBT+Ntl09SWq/XZu3mi6XurR2t4iS3nkASy nuBMCRrK75wYaq+H2BEljjtRMedKi35xPW4VlyOtj0P4uA9C9nEsP/G4nzNEzCnHGM0ZXZ LAMDtE+CoUeWVMeX5Gip8w46+krq1O4HXmfyzL3eXndP47UAINBw5SxSGnK00w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1654864125; a=rsa-sha256; cv=none; b=baLrMoehEl++W4v8SngTasnGEcQho0YD95ZRNVwQBSY5FaVerDxwYWUqSgBY5NAFQ/odtC sc3NV+08uUMNyyEqJGQV8BSQYgm96QjR3Vzl2eZHLaPU/ndY3CAYC0PSeo14nAv6nIo+DX JxoGnp+fbDaERx3/iLmSeuwatre+w4WAobHpL91NUBF+o7ylwQlqcP3x5Q57sAZg5usOvJ NWd4QThOTNS/VqiLtgfdlbGAuGQYXTaFBEdkml9lOmLkIjQf1NSrFw6sXoctgQZ0OBkWtC aA6Kjmszejrp8rKBdS+76bdpUNJYmyl6dF/LIGKrlu6WI5t72CQcpg1igIy3PQ== 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" X-Migadu-Spam-Score: -3.88 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-Queue-Id: 44393F7C9 X-Spam-Score: -3.88 X-Migadu-Scanner: scn0.migadu.com X-TUID: KIfe60D+WR8h --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Arun, thank you for your detailed analysis! Arun Isaac writes: [...] > I meant that Guix has very high coding/packaging standards in the > following senses: > > - We prefer to not bundle dependencies. Tracking out bundled > dependencies, git submodules, etc. and figuring out how to rewire > everything so it works with unbundled dependencies can be really > tricky for some packages. more than tricky: sometimes /impossible/ this is a /huge/ complex issue (I know you know) that some upstream developers simply ignore; in a sense I feel that Guix was developed /also/ to help solve this issue and avoid programmers to invent too creative ways to distribute theis software dependencies ...but it's a hard work, it needs... zen discipline anyway: AFAIU all of us do agree that this requirement is a Good Thing=E2= =84=A2 and we have to keep it as a "core requirement" also, AFAIU there is no way Guix maintainers can help in making this process easier or automatic: right? > - We build strictly from source. This is also a requirement now adopted by many other distributions, at least all the ones in https://reproducible-builds.org/who/projects/ > - We aim to package tests for all packages. is there something different that should be done? do this requirement (is it a requirement?) need to be better documented or discussed? > - We have strict conventions for commit messages. Our commit message > Changelog is a strange dated practice from the time before good > version control systems. I can live with it, but not everyone likes > it. Let's just say I've heard complaints about it offlist. AFAIU this is a requirement Guix inherits from GNU (being it a GNU project) I don't remember the ratio for this requirement but AFAIU it made sense to me when I read that. I just hope this requirement is refraining people to contribute and to review patches. Maybe we could help users not using Emacs with other editor-related snippets in [~/src/guix/]etc/snippets? (I don't know other editors templating systems) > - We don't just list the main license of a package. We trace out the > license of each and every file, if they are different from the main > license. Is it possible to write an helper tool?!? I have still not searched for one such tool, maybe other distributions do have such a tool? BTW AFAIU this is a legal requirement we cannot avoid, even if sometimes it's avoided by some upstream author > - Our synopses and descriptions are not casually copy-pasted from the > project website. We try to rewrite and improve on them if necessary. AFAIK similar requirements are "enforced" by all other distributions > - We have to be careful about pushing changes that will cause too many > rebuilds. We have a core-updates process for that. Could this be automated by a pre-commit hook? [...] >> please can you expand on this? What is that cost of failure? > > The cost of failure is mostly in the mind. A commit is something that > has your name on it and lives on in the repo history *forever*. So, it > better be good. That's the pressure. I do have one or two commits in the > guix repo with badly borked commit messages. OK thanks, I understand [...] >> specifically speaking, IMHO in cases like this you should send an >> email-reply to that bug (patch) explaining the 1% you are unsure of > > Yeah, I would. But, often that 1% is too nitpicky to be worth > reporting. Sometimes, I fix the 1% myself and push. But often, I confess > that I just leave it to other committers. I don't imagine a specific use case, but nevermind [...] Thank you! Gio' =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmKjOMAMHGdAeGVsZXJh LmV1AAoJENN9DqfOzDkS2kQQAMNjgkttD8L7OOChrCltXOZg4E96vQbKgospET4W sbCH/beWj8/mXagCpxicWHmknMxhoHnFuYYxVaml1xD+vzh69x35v2PQPQNqj3Xx uNagK42nhZaJc/xqTlv4ZTYCPLT8e/qqdkx9TE+kTCX1VXnybCkYIn2LKzrCcy9g O3bvEVVAFZNYHhD5B3rbFz+hTN+gTEm+D6TS6VUqkVEqBFy3rhWrcanf0VkQwVY5 fcT8fwWNv1utrhWI/xHr/vxyu/IIVBqvGjGVMzQp5rCRVTQcZaLIUaDofz8lNZrp pV+q3vg9m5Sc+y7GkeBQZY/z3GGQtIuA1fKW7VwfH0JbT0txx8HG677Zz5eKSFue d0HysRS/mID6bcSIjxwQ6quxd+Vx71tr6Hq3x6H5auJTHUNEsgXJX7yJhsIvPNR6 49OhHRWmYNA71ji1ejUns0GgLp3AuezKa79D7XFKGnE03FEQDGKrbIITZbhAZy/A O1Gs4vOSSONRY7VZ0Y9OPbWgrlttvPSnBTtmWA60K0u7jifKFnNnOYjJnNt4EJiJ uvUyGha7gXvwjxFJM5weYHKrl0iDdznHch+lVIXRErdT4kIpuJVBjL+w/cmDNuWO Pt4uVqiU8Tv45kJbast1zZ4pJxRCMo4aVSjMCBGkfjuN+ydXMxHqV9o/odIFQFsr Hkp0 =ggVa -----END PGP SIGNATURE----- --=-=-=--