From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id mFVQJrqkqWJjGwAAbAwnHQ (envelope-from ) for ; Wed, 15 Jun 2022 11:22:02 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 8KxGJrqkqWJr/wAA9RJhRA (envelope-from ) for ; Wed, 15 Jun 2022 11:22:02 +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 4257143B56 for ; Wed, 15 Jun 2022 11:22:02 +0200 (CEST) Received: from localhost ([::1]:56328 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o1PDs-0000iT-CU for larch@yhetil.org; Wed, 15 Jun 2022 05:22:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60290) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o1PBP-0000J1-Dk for guix-devel@gnu.org; Wed, 15 Jun 2022 05:19:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57378) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o1PBN-00030y-G8; Wed, 15 Jun 2022 05:19:25 -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=dx0EY4NmpxL1ogH8Ge6TjJWdYsCsEVL5I3WBTHQnGY0=; b=bDotJGsRtRaed6R37AQY e/0XMzTY1egzebKaXUtWFDz5F+8QwQ7/WxoQsFhAEkq4E78QaoF7HtXDbwmkX8RVEKaYt24kzN6MP 4f2LNDpByKsKBf7YMr/rnDlU8ZJTMXbqHQ7UG2Bc/xcxs9ilqxoAMOD2R9MKmQ9a50YF1IhoofQ+f fdq26LifZQO1aDsrdaGdq1JMpk5ZXHgTIvrvVTGnt6at8YmaGdF6nFTQMMFOZ1aKuttVA7n1jDnw1 eALvuWoO0ERHN6+Mcc9Sx+2XkGhQvAzqrI5j5veaDJE/YSSAI1ckLvgp5b6qmz8Pga3G4fHm8S8VZ 6vWaLg5jiZg/wQ==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:60693 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o1PBM-0006rD-Vw; Wed, 15 Jun 2022 05:19:25 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Arun Isaac Cc: zimoun , Giovanni Biscuolo , Guix Devel , GNU Guix maintainers Subject: Re: On commit access, patch review, and remaining healthy References: <86fsk7cu1i.fsf@gmail.com> <87lety2ywg.fsf@systemreboot.net> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Septidi 27 Prairial an 230 de la =?utf-8?Q?R=C3=A9vo?= =?utf-8?Q?lution=2C?= jour de la Verveine 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: Wed, 15 Jun 2022 11:19:22 +0200 In-Reply-To: <87lety2ywg.fsf@systemreboot.net> (Arun Isaac's message of "Wed, 15 Jun 2022 12:31:35 +0530") Message-ID: <874k0muvvp.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=1655284922; 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=dx0EY4NmpxL1ogH8Ge6TjJWdYsCsEVL5I3WBTHQnGY0=; b=MVAZKuigS9ypi3Q1/8YvUlvBD8aMKjkyx/Lm46bglOPgmPRyGI36k4K0ibqYkihU2wn/eG xLQ7xhRFr6omX518Z9a1N5h2R9dGQ+BzLBwZ4f/NgBKM7Pa3wDZE117IouFi1n5pwEyhXH jk9M5UkOn74DBrxjxHxvYaATZc80QlBME+roHRA1rpvWskZs34PHwiDdG7dhjZl1Cn2Lw7 oCgltM8krEatTsxyRkjhQvH5gD4roIysjI2cxXbZrB7TPEEw2V3gJofyj2VDzZ4Ay1guJv hjJ52dI9UdFf3YQdrHxq/eKDXp7ffxJTPyI/EDPDE5O6Bwj6TediEMxF070QJw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1655284922; a=rsa-sha256; cv=none; b=OTaXZAX5PRHamQxZ7cm0Ir5CfrAQ3mYg78og8/nxYnzNY0/Sl1shnogtciQRYU7In6Ucnw WtvSba2yBlBy4x37xbIeum0ftXoQEqEPTwNilVMUV0gmfWntwogtO1C5MRTWFMFHrQoOTN M7BLHRNJrtSJs0UVIM1jXxEFf+rjKUb9EkJLJkVM3/ev44mmV5WL2guxpC8HWwncy8IXUl P7SPVv32XTAnQd/eqbVTQzr1fptw61Y9QfiCoBC3qYbl66gYesolTDzHer1541s1t79t/t MGvcGh/trO2T5R6Qy7N+8pblV5w8v2zaghxgxqpICjCJ1FPsprnFLCUfkz7cbg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=bDotJGsR; 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: -3.69 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=bDotJGsR; 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: 4257143B56 X-Spam-Score: -3.69 X-Migadu-Scanner: scn1.migadu.com X-TUID: H+sLGPsv2/0M Hi, Arun Isaac skribis: >> That=E2=80=99s why, I think the project should: >> >> 1. change the default branch of =E2=80=9Cgit push=E2=80=9D vs the defau= lt branch of >> =E2=80=9Cguix pull=E2=80=9D. >> >> 2. add a bit more of checkers on patch submission easing patch >> review. > > I like and support both these ideas. Maybe, they are even long overdue! > ;-) I like them too! #1 is more involved than it sounds though: there would need some tooling and/or human intervention to merge things from the push branch to the pull branch. I don=E2=80=99t have a clear idea of how to do this. > I would also like to raise a couple of more controversial suggestions: > > Should we restrict the set of packages that will be accepted into Guix? > Currently, we accept practically any free software package into > Guix. Should we limit the number of packages we will accept in order to > ease maintenance? "Minimal" distros like Arch Linux do this, for > example. > > The cons are that, say if we reject packages involving difficult > languages (think javascript), we may alienate a section of our users > (and potential users) and thus inhibit further growth. If we go down > this route, Guix may never grow into an "universal distribution" like > Debian is. I=E2=80=99ve been wondering about that too. Clearly there=E2=80=99s a tens= ion here. The main difficulty as I see it is how do we draw a line? For example, assume we came up two years ago with a policy to not include Rust packages and instead have them in a guix-rust channel. Two years later, Rust has become a dependency of a number of core packages, so we have to have Rust, or at least a large subset thereof, in the main channel. Then there=E2=80=99s the question of leaf packages (applications): how do y= ou assess the usefulness of an application? How do you determine that an application is no longer used? > Also, should we remove old/broken/unused/rarely-used packages from Guix? > In the past, I have packaged and contributed very niche packages which > probably no one else uses, and sometimes even I don't use anymore. But, > these packages continue to stay in Guix and add to the maintenance > burden. Should we have some policy to phase out such packages, > especially if such packages break often? I mean, that there is no need > to phase out an elisp package that builds trivially all the time, but > what about more complex packages that take many many hours to maintain? I think we do that from time to time, but it=E2=80=99s an entirely manual process. Sometimes a patch to remove a package triggers a reply with a patch to fix that package=E2=80=99s build process too (I=E2=80=99ve done th= at a couple of times :-)). What could help though is a dashboard, in Cuirass or in the Data Service, that would display packages that have been failing to build =E2=80=9Cfor some time=E2=80=9D. Thoughts, Ludo=E2=80=99.