unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Léo Le Bouter" <lle-bout@zaclys.net>
To: guix-devel@gnu.org
Subject: A proposal for better quality in maintenance of packages by reducing scope
Date: Tue, 23 Mar 2021 16:00:42 +0100	[thread overview]
Message-ID: <1b2c22892d9cde9b86ff96cc70cb89ad17fba807.camel@zaclys.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

Hello!

There's lots of packages in GNU Guix and maintaining all of them is
tedious, even if we have tooling, there's only so much we can do.

I want to have a secure and reliable system, I would also like to only
depend on packages I know are easy to maintain for GNU Guix
contributors.

I would like to propose that we reduce the scope of the maintenance we
do in GNU Guix and establish a list of packages that we more or less
commit to maintaining because this is something that we can do and is
attainable, for example, we could remove desktop environments that we
can't maintain to good standards realistically and focus our efforts on
upstreams that don't go against our way of doing things, that are
cooperative, that provide good build systems we can rely on for our
purposes, etc.

I propose we also add some requirements before packages can go into
such a maintained state, like a working and reliable updater/refresher
with notifications directed to some mailing list when that one finds a
new release, a reduced amount of downstream patches and a cooperative
upstream with who we preferably have some point of contact to solve
issues or gather more insider knowledge about the software if we need,
a working and reliable CVE linter with proper cpe-name/vendor and
notifications going to a mailing list we all subscribe to, etc..
probably lots of other things are relevant but you see the idea.

It should also be possible to filter out packages that are not declared
to be in this maintained state, for example, in the GNU Guix System
configuration.

Some kind of quality rating for packages that users can trust.

What do you think?

Léo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

             reply	other threads:[~2021-03-23 15:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-23 15:00 Léo Le Bouter [this message]
2021-03-23 15:48 ` A proposal for better quality in maintenance of packages by reducing scope david larsson
2021-03-23 20:57 ` Christopher Baines
2021-03-30  8:35 ` Ludovic Courtès

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=1b2c22892d9cde9b86ff96cc70cb89ad17fba807.camel@zaclys.net \
    --to=lle-bout@zaclys.net \
    --cc=guix-devel@gnu.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).