all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: John Kehayias <john.kehayias@protonmail.com>
To: Maxime Devos <maximedevos@telenet.be>
Cc: Trev <trev@trevdev.ca>, guix-devel@gnu.org
Subject: Re: Stumpwm Contrib Packages
Date: Tue, 04 Oct 2022 21:50:16 +0000	[thread overview]
Message-ID: <871qrnmf71.fsf@protonmail.com> (raw)
In-Reply-To: <1c88d449-c7ec-8a89-e37d-c149d0ae8f1c@telenet.be>

Hi all,

Bit late here, but as a StumpWM user (and having a module I adopted from someone, 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 easier 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:<https://github.com/stumpwm/stumpwm-contrib>
>> The inheritance I am referring to is here:
>> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/wm.scm#n1942>
>> 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 components _within
> a single version_ remain compatible, and that by picking a separate commit 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?) of the modules are independent and written as separate lisp packages. I haven't checked this in detail, but that's my understanding; it is useful grouping to have all the stump modules together.
2. I've found the development speed for contrib to typically be on the slower 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 change other modules.
3. I can't say I've had any problems due to any incompatibility between modules and any bug I've hit have been ones that have been lying in wait rather 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 something 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



  reply	other threads:[~2022-10-04 22:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-11 15:02 Stumpwm Contrib Packages Trev
2022-09-17 12:28 ` Antonio Carlos Padoan Junior
2022-09-17 12:53 ` Maxime Devos
2022-10-04 21:50   ` John Kehayias [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-09-18 16:11 jgart
2022-09-18 16:32 ` Trev
2022-09-18 17:14   ` jgart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871qrnmf71.fsf@protonmail.com \
    --to=john.kehayias@protonmail.com \
    --cc=guix-devel@gnu.org \
    --cc=maximedevos@telenet.be \
    --cc=trev@trevdev.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.