From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id iLuIOEwE4mVWbgAAqHPOHw:P1 (envelope-from ) for ; Fri, 01 Mar 2024 17:37:33 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id iLuIOEwE4mVWbgAAqHPOHw (envelope-from ) for ; Fri, 01 Mar 2024 17:37:33 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=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"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1709311052; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=ENf8Sgk7UtWDcXfx6ZtjutEImsAt3rKN60x+1ivehEE=; b=kTg1q2BdracrIYVwpMyr39yqYBvxiJRpH/ZORGBey1S9yfhwP3sBX4cLf9gmeFZ0+0YwnW UxVOGYsMKAGC7LJ8Ma9BDDYsLgKEZmhh/cVIoiFUKkU1oocAgA9X55heW7WRdXhQ/RF+DN XbZEQPlmcxnC2CQylD6ew995YktkLIZgw+xMFRgaRm5A7fKwIzZOIMgCOiCf30T4Y/2Hcz AEBCjFU0HieRjiwZkK0Z1EE5TZppI1BkJANunK/aVGnCgQzQQuu4wFgZJJy2FSSDYqhiwW XaQ5JvebF1e1/g1o+/D48yz79Y/8KXg9yJRDjDmAQK/3nNZbL/LOGzMnwoKL3g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=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"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1709311052; a=rsa-sha256; cv=none; b=hAOX/kHv99CPbWDGDqYoniWvFLdC0qeYdl6f3eIaEbYyccO1Ih+Om26jb8LudAH0zBPjKJ tejjxiEXQyxiXhIxUb8JcM7EqM0wO7UQz/LmDeYaREwWnUQxHK1UQfpu7Qo+Ir4SQdRehv Rt/CnXkFRqqztld9nASCutGtG3puqxmVtX7SNPqiGjJhys/JEbWi2K68nKnQDFJcxIwx6K oF0kT2ig3IB8WtSQzUVwvpERnyUdTTXK1wXP1RyPQY1CpZ+uCI7fdsuIPpPNp41RTUQPa2 +Vg1KfsFPPxG/oXgIQjhUmoM0RvhRmWtCcbWnMoK3MK5gnx9kMrZ6mwCinaHAA== 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 96F8768AB6 for ; Fri, 1 Mar 2024 17:37:32 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rg5sg-0000ZK-OM; Fri, 01 Mar 2024 11:37: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 1rg5sd-0000Yy-Cd for guix-devel@gnu.org; Fri, 01 Mar 2024 11:37:03 -0500 Received: from mail01.noris.net ([62.128.1.221]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rg5sa-0005L7-LV for guix-devel@gnu.org; Fri, 01 Mar 2024 11:37:03 -0500 Received: from p5b394e79.dip0.t-ipconnect.de ([91.57.78.121] helo=[192.168.110.2]) by mail01.noris.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim) (envelope-from ) id 1rg5sW-0003EU-3R for guix-devel@gnu.org; Fri, 01 Mar 2024 17:36:56 +0100 Content-Type: multipart/alternative; boundary="------------SWbahbJXAXEOVeMBH8xe0va8" Message-ID: Date: Fri, 1 Mar 2024 17:36:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Content-Language: de-DE, en-US From: Hartmut Goebel To: guix-devel Organization: crazy-compilers.com Subject: Contribute or create a channel? X-Noris-IP: 91.57.78.121 Received-SPF: pass client-ip=62.128.1.221; envelope-from=h.goebel@crazy-compilers.com; helo=mail01.noris.net X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL=1.31, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -0.55 X-Spam-Score: -0.55 X-Migadu-Queue-Id: 96F8768AB6 X-TUID: wO+5bRO5muk1 This is a multi-part message in MIME format. --------------SWbahbJXAXEOVeMBH8xe0va8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm currently updating Tryton to version 7.0 and am wondering whether it's better to contribute the change to Guix or to set up a channel for Tryton. WDYT? I'm eager to learn about your thoughts. Here is why I'm wondering: * Tryton consists of a client, a server and about 200 module/add-on providing business logic. * Tryton publishes a LTS version every 2.5 years. Two LTS versions are supported (currently 6.0 and 7.0) and bugfixes are backported there for 5 years. * Every 6 month a new release is crafted (x.2, x.4, x.6, x,8) which will get bugfixes for1 year. Releases typically provide new modules (which is why updating is of interest) , might change inputs and might require database updates. * 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 . Given this, it might be interesting to have three versions of Tryton available: the two LTS versions and the latest version. Now the idea is to provide a channel which provides a branch for each LTS version and a "main" branch for the latest release. This would allow to checkout the respective branch and refresh the packages of the respective version semi-automatically. OTOH in Guix, maintaining several version seems laborious. Anyhow I'm unsure whether it's worth the effort maintaining three versions and whether I'll be able to keep three version up to date - esp. given that I don't have much automation for this. Some more background-info: * 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. * Debian as of now provides packages for 6.0 only (7.0 was released ) -- Regards Hartmut Goebel | Hartmut Goebel |h.goebel@crazy-compilers.com | |www.crazy-compilers.com | compilers which you thought are impossible | --------------SWbahbJXAXEOVeMBH8xe0va8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi,

I'm currently updating Tryton to version 7.0 and am wondering whether it's better to contribute the change to Guix or to set up a channel for Tryton.

WDYT? I'm eager to learn about your thoughts.

Here is why I'm wondering:

  • Tryton consists of a client, a server and about 200 module/add-on providing business logic.

  • Tryton publishes a LTS version every 2.5 years. Two LTS versions are supported (currently 6.0 and 7.0) and bugfixes are backported there for 5 years.

  • Every 6 month a new release is crafted (x.2, x.4, x.6, x,8) which will get bugfixes for1 year. Releases typically provide new modules (which is why updating is of interest) , might change inputs and might require database updates.

  • 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 .

Given this, it might be interesting to have three versions of Tryton available: the two LTS versions and the latest version.

Now the idea is to provide a channel which provides a branch for each LTS version and a "main" branch for the latest release. This would allow to checkout the respective branch and refresh the packages of the respective version semi-automatically.

OTOH in Guix, maintaining several version seems laborious.

Anyhow I'm unsure whether it's worth the effort maintaining three versions and whether I'll be able to keep three version up to date - esp. given that I don't have much automation for this.

Some more background-info:
  • 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.
  • Debian as of now provides packages for 6.0 only (7.0 was released )


-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |
--------------SWbahbJXAXEOVeMBH8xe0va8--