From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id GEyTCLwb4mVmmgAA62LTzQ:P1 (envelope-from ) for ; Fri, 01 Mar 2024 19:17:32 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id GEyTCLwb4mVmmgAA62LTzQ (envelope-from ) for ; Fri, 01 Mar 2024 19:17:32 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=laesvuori.fi header.s=mail header.b=PcgOdiwF; dmarc=pass (policy=reject) header.from=laesvuori.fi; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1709317051; 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:dkim-signature; bh=wexeOJugoDlPQ8jJzs4Dx6G/uG1V9MG895bTA/Y+AfE=; b=JUaKhRyfotOThxqjd/E3JrbtzDv1vVzbbvyIpzrWOywbQhY5FuUvQzXRg/Et3xpQRtOd5M 0ELzkqeXInkaqS/L0OsHeT11vyxX3TIs1NYvZHod4xaExNtyIAzaaW+k/Gi4VvFgGxAcQ6 7Svwh6YDRTUihJ1uoxDryXKRyLWuAHnzLqGJZE/voNkFWTiQCEFjKCMpZXq4DuEhl3ZT+w 7i64C3uzG7bFwmhF7M7VDsMs7lOi0YoeCsXSZdHlLwDVHUvhgQuLylwwjlu2upSBNOPr6c Upfr/K0cT5HGU8hz+RsA4IPBX0B2uxLQHn74r7DSB2HYvth06sHegCInbhjDpA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=laesvuori.fi header.s=mail header.b=PcgOdiwF; dmarc=pass (policy=reject) header.from=laesvuori.fi; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1709317051; a=rsa-sha256; cv=none; b=mWTRvJkk2lJi5qtwjhgJcdhm67Lsmjhh5AyANIXXIzqkxE29bwNHjILmubTbojJJZgRUgB mGVk3wQDUNlwWtr9mmk1HbTHRZugDE6o9xQegUXPEaHbJif7bBjUyPiDkN0nE6vU6wyzXV PdFLTSL4ROqn8N4GJrZ450cufrQd5Vouzn054cMoTaE1VMxhmvDPPo2uZdPUWQYtMJdqp5 9SiPyN+USW1cqqWA+lMDvVs3hEhkyOX6L1W79VwNcHEdGnvp2WD/r7cpmhBBjZCCYa+8Va Kad54eaSH8dwdR7QDu50C7QxdZSVU2FbTI7HGN8YIZ7IFUoX1+aGYdYLkg1iOA== 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 B8B0712B89 for ; Fri, 1 Mar 2024 19:17:31 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rg7RS-0006nW-Fz; Fri, 01 Mar 2024 13:17:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rg7RQ-0006lv-Tq for guix-devel@gnu.org; Fri, 01 Mar 2024 13:17:04 -0500 Received: from vmi571514.contaboserver.net ([75.119.130.101] helo=mail.laesvuori.fi) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rg7RP-0005iG-38 for guix-devel@gnu.org; Fri, 01 Mar 2024 13:17:04 -0500 Received: from X-kone (88-113-24-127.elisa-laajakaista.fi [88.113.24.127]) by mail.laesvuori.fi (Postfix) with ESMTPSA id 13F833400F9; Fri, 1 Mar 2024 19:17:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=laesvuori.fi; s=mail; t=1709317064; bh=42wDqjEnAvCnx8G6THQbtrF+5TYnITs9z3iuS7cVDPg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=PcgOdiwF69Az4x2Boowmg8ZasDKASAMk2icTbGczrByz7sunQHpjNWm1xiAQ8lCQD 6t+Woo4va8l2WbTXbjJce/NFXkR+lCLt6O/bhc0+AwqSelkUZ/HmUNZKpao8c8+q5w Zj9uLuyZUyyb4AGTYkMr5VvhttL/ec7u0zKT/3I0= Date: Fri, 1 Mar 2024 20:16:54 +0200 From: Saku Laesvuori To: Hartmut Goebel Cc: guix-devel Subject: Re: Contribute or create a channel? Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4e6caosrcypmvoso" Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=75.119.130.101; envelope-from=saku@laesvuori.fi; helo=mail.laesvuori.fi X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.28 X-Spam-Score: -9.28 X-Migadu-Queue-Id: B8B0712B89 X-Migadu-Scanner: mx13.migadu.com X-TUID: 94xcMzS4ASuQ --4e6caosrcypmvoso Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > I'm currently updating Tryton to version 7.0 and am wondering whether=20 > it's better to contribute the change to Guix or to set up a channel for= =20 > Tryton. As a general rule: it is always better to contribute a change instead of maintaining a separate channel for it if the change could be accepted in Guix. > * Bugfixes happens rather often and per-module, since they are > published even for smaller fixes. Upstream promises to not contain > functional changes or change requirements. Each bugfix could be > implemented as a graft, since . I don't think it would make much sense to implement bugfixes as grafts if the package isn't depended on by a huge number of other packages. > Given this, it might be interesting to have three versions of Tryton=20 > available: the two LTS versions and the latest version. >=20 > Now the idea is to provide a channel which provides a branch for each=20 > LTS version and a "main" branch for the latest release. This would allow= =20 > to checkout the respective branch and refresh the packages of the=20 > respective version semi-automatically. >=20 > OTOH in Guix, maintaining several version seems laborious. It just requires a different updating method. The different versions can just be defined as separate packages (see postgresql for an example) and the user the defines which one they want to use. They can either refer to the package variable directly in scheme (e.g. postgresql-15) or on the command line with the name@version syntax (e.g. postgresql@15). > Some more background-info: >=20 > * Within each version, there is guarantee that the database schema > will not be changed. Anyhow between versions the db schema might > change, requiring manual migration steps. This is the case with postgresql, too. (which is why I chose it as the example before) - Saku --4e6caosrcypmvoso Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEoMkZR3NPB29fCOn/JX0oSiodOjIFAmXiG5YACgkQJX0oSiod OjIKQRAAkcfWUSfE2B5Pnzo7rMpptFz/vZTObgHmHygUYk5JLzxUakAiaIuFEKOf 1uRNd6oT8iKCiy/7ZT+n/vSUhPp87AZNZg15bZuoFpqyZf7J432OBN68rdYS+v2P hSLI30Rrly5DhoIpiUdgpm/d/kEuEPE8+54BY785jSSqvpZGGVUpgTePxggg3D/4 uj/pqtPRUYmWUQO3+exdrk2RrOGs7AcrjJUUSIrAB5TTdJsVaehSJ+Cj4oWl2deq UIZU5FyJatqmB/QT5S27/+vDDHikCOJZDCt8i/UNYRvBmM2bw0qS+RyDlRB/6WrC DRgSZ31uj4vLkkb6IniPshAJ6tpHsG5hzP766+xQFtp9BZIlcX87NDQati58br5i OVxw9w0hy4vciTkAyQ8PEoDfrHidoC/oin/X5yeLv/dOUqdeSDhM0QlkVgmcazYm g5N1WmKNEsnKfZriKXedHMILTPaXWmQBj8SwKXzBuQGbYgTWxvB8KLavz8YfWfof DGKw0objbwfTv6xnf7rSoDXLSQqy7fW6MBFady3Mogm2ZJVmivBmPE7SpKl1w8kV hkA7vnHBaX3vgEb8HJLPzDp1eIaZh44SBQZHGxVCEi3E7aC3kEdTaLH6/LS9ic3q daN9yC2TNAsfOW3842rx9f065DO+VLSBVkw6PM4rTZH9RWpFY40= =p6oM -----END PGP SIGNATURE----- --4e6caosrcypmvoso--