From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 AGa+HGatPGNmEAEAbAwnHQ (envelope-from ) for ; Wed, 05 Oct 2022 00:02:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id wAafHGatPGP4cgEAauVa8A (envelope-from ) for ; Wed, 05 Oct 2022 00:02:14 +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 0927441CE7 for ; Wed, 5 Oct 2022 00:02:14 +0200 (CEST) Received: from localhost ([::1]:38922 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofpzR-0002jB-5b for larch@yhetil.org; Tue, 04 Oct 2022 18:02:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32772) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofpo7-0001HB-Kr for guix-devel@gnu.org; Tue, 04 Oct 2022 17:50:32 -0400 Received: from mail-40131.protonmail.ch ([185.70.40.131]:47449) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofpo4-0002ye-8T for guix-devel@gnu.org; Tue, 04 Oct 2022 17:50:30 -0400 Date: Tue, 04 Oct 2022 21:50:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1664920225; x=1665179425; bh=Wd+FTziwAmoxLjdqCWCaOr7FT5VtvLKoaAdXakRhXnM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=YnPjHaiCdtd5xQPMDTswqOHGIyHrsRPT0943KX433TbMBJmERv+GQaN4kLaQjhVPF NIQMZOVPY6PVxjhQNEuNzNQrvIfmAGTYTaUVCufzRMt82ItzVC1QYJ0VeK7DRsH1Be AA57XCD9QwzQJDP5dVeUILQWdUS8eaXkgtoNjCDq6q8EWftmj08FJMOhGOgm8x915i xVIqJAEk9OqTeBEdDFnYcibKs/bcTRzTjbWb0RX27XbKpEM5s6a3qwubmOLFRLJ405 yopZvx34n4i8hGttke/qIk3wFIbXvwoRNxIHs2vJCT9w3aZ2jfVpVsg5zbifgQVkuX M4T4+SeuquO8Q== To: Maxime Devos From: John Kehayias Cc: Trev , guix-devel@gnu.org Subject: Re: Stumpwm Contrib Packages Message-ID: <871qrnmf71.fsf@protonmail.com> In-Reply-To: <1c88d449-c7ec-8a89-e37d-c149d0ae8f1c@telenet.be> References: <87o7vmlzso.fsf@codinator.mail-host-address-is-not-set> <1c88d449-c7ec-8a89-e37d-c149d0ae8f1c@telenet.be> Feedback-ID: 7805494:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.131; envelope-from=john.kehayias@protonmail.com; helo=mail-40131.protonmail.ch 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, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 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-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1664920934; 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=Wd+FTziwAmoxLjdqCWCaOr7FT5VtvLKoaAdXakRhXnM=; b=PGdDcgBBgobjE+3EJ7LbIdnBX6GrhSJVDjVarVu+11+Q4YH7I8j/WDaSY4e3vfqDknhtMK OAdnJL4fN2sEcZsNAiZenVNeiJU1yEnVoCh3javmpmJ5BXMqt39xsT+ZOgzWUBw3XBCoYo Oo/CW0Do5Xip4+8xfLtDwxrWi3kZiIsUmavso1OF0oeYKe/g922zC7K3kJ1xQemQRj3/E/ eA1ZMgjCLhrkJvZuOvG/WxpwADK5Nj1CGVTAP6yR0QJuKKK/E4pJzdMjKoalgBSlHpAFuR 4bnJEdKCvaU7pU7rAy7N94zhSQ39EjyoTaFZXMtUtWAcBIDd/XJIiELbwHYd/A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1664920934; a=rsa-sha256; cv=none; b=kdNMKwBLwwolhKf8H5Q4W50gMbev25hT8NvG0HuviVixY/2U+ePjikLTPazPbXNcuP32UA VwKhw0/5ljnho1aMPhJ5g489MEOhdb5Kp50Roj7pR9RPX8Pp9+7zOGtrljUKCwIvkEpNBk GFxxE5gk8J9ssUb2Tjr/2GPtO4fuFw0b2W6NPZtKcT8OKgmU7Vn25RJfY+M010unoV914w 7ooJipRYvQzzhZCEqxrw1hJK5moAhzL9bt1VboZWBem/vf1AKRxqkhocFIJeqimXim0roJ uhgEoK1RcpE4zOXg60Uy3WrVaAy0Stc88qQYsTSm2qaZXwbNnAVVylhZr5Wktg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=YnPjHaiC; dmarc=pass (policy=quarantine) header.from=protonmail.com; 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.66 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=YnPjHaiC; dmarc=pass (policy=quarantine) header.from=protonmail.com; 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: 0927441CE7 X-Spam-Score: -3.66 X-Migadu-Scanner: scn0.migadu.com X-TUID: 8JVjfVYr52iY Hi all, Bit late here, but as a StumpWM user (and having a module I adopted from so= meone, but maintained outside of the official contrib repo) thought I would= chime in. Though in my personal config right now I use a local checkout of= the stumpwm-contrib repo rather than the Guix packages. I think that was e= asier to set up at first and need to look back at it. (And that reminds me,= should contribute that module (scratchpads) to upstream stumpwm-contrib.) On Sat, Sep 17, 2022 at 02:53 PM, Maxime Devos wrote: > > On 11-09-2022 17:02, Trev wrote: >> Hey Guix, >> I am trying to decide whether or not to contribute a refactor of >> stumpwm-contrib in gnu/packages/wm.scm. It feels like each contrib >> module should be its own package with its own checkout and that it might >> be a bad idea to update all of the contrib modules through one common >> ancestor. >> If you are not familar with stumpwm and stumpwm-contrib, you can see the >> source repository here: >> The inheritance I am referring to is here: >> >> My reasoning for this is that if breaking changes are introduced to one >> module, but wanted updates happen to another, it would be nice to avoid >> the breaking changes and get the updates. > > If the stumpwm people put lots of components in a single > 'stumpwm-contrib', I expect that they take care of making sure all the co= mponents _within > a single version_ remain compatible, and that by picking a separate commi= t for each > component in Guix, it is likely to encounter incompatibilities (breaking = changes). > >From what I understand and my experience, a few comments: 1. While grouped together in one official git repo, I believe most (all?) o= f the modules are independent and written as separate lisp packages. I have= n't checked this in detail, but that's my understanding; it is useful group= ing to have all the stump modules together. 2. I've found the development speed for contrib to typically be on the slow= er side (less active than the main stumpwm repo, for instance), so I think = this makes it less of a concern. Updates tend to be per module per commit, = so if something breaks in a commit, moving to a previous commit wouldn't ch= ange other modules. 3. I can't say I've had any problems due to any incompatibility between mod= ules and any bug I've hit have been ones that have been lying in wait rathe= r than introduced by current work. > In the hopefully rare case where we encounter an incompatibility, we can = still choose to > override the checkout for the impacted package. > Yes. Or of course locally using a package transformation (include a patch),= local definition, or perhaps via the local stumpwm config to override some= thing in the module after loading. > As such, I recommend keeping the status quo. > I can see why someone would want to separate the sourcing, but I think that= adds extra maintenance. I could go either way. John