all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Msavoritias <email@msavoritias.me>
To: Richard Sent <richard@freakingpenguin.com>
Cc: 71700@debbugs.gnu.org, zimon.toutoune@gmail.com
Subject: bug#71700: The Archiving functionality of guix lint should be opt-in and Documented more prominently
Date: Sat, 22 Jun 2024 17:24:19 +0300	[thread overview]
Message-ID: <20240622172419.477c5b32@fannys.me> (raw)
In-Reply-To: <87iky1azb6.fsf@freakingpenguin.com>

On Sat, 22 Jun 2024 09:21:01 -0400
Richard Sent <richard@freakingpenguin.com> wrote:

> I think channel level configuration of some form for code archival is a
> good idea so individual channels can choose to disable it. I also agree
> that we should make the fact that guix lint does archival more
> prominent.
> 
> I disagree with a statement that permission is required, but I'll avoid
> rehashing the discussion ongoing in guix-devel. [1]
> 
> I think there is a good reason to support disabling archival at the
> channel level. Simon, do you think your patch can/will manage that?

That is still missing the usage of people wanting to run `guix lint` without having a channel.
A channel level mechanism would be nice indeed but we still need a way to account for the archiving functionality for people who dont have channels or dont run channels.
The proposal of making it explicitely enabled would work as a solution for that use case.
That way the channel configuration would be to enable it instead of disabling it. opt-in/opt-out and all that.

It also avoids the mistake of not realizing it exists or is enabled and accidentally somebodys code ends up in SWH without them meaning too.
Not everybody reads the manual after all and we shouldnt do stuff we havent been explicitly required to do.

In short I would say a channel level mechanism would help to "automate" the opt-in of running `--archival` everywhere with `guix lint`.

MSavoritias

> > Somehow I disagree with this.  And I propose the generic approach that
> > allows to exclude any checkers from the package definition using the
> > field properties.
> > 
> > See <https://issues.guix.gnu.org/71697#1>.  
> 
> [1]: https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00192.html
> 





  reply	other threads:[~2024-06-22 14:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-21 16:45 bug#71700: The Archiving functionality of guix lint should be opt-in and Documented more prominently MSavoritias
2024-06-21 18:46 ` Simon Tournier
2024-06-22 13:21 ` Richard Sent
2024-06-22 14:24   ` Msavoritias [this message]
2024-06-22 15:30   ` Simon Tournier

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=20240622172419.477c5b32@fannys.me \
    --to=email@msavoritias.me \
    --cc=71700@debbugs.gnu.org \
    --cc=richard@freakingpenguin.com \
    --cc=zimon.toutoune@gmail.com \
    /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.