unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / Atom feed
* A proposal for better quality in maintenance of packages by reducing scope
@ 2021-03-23 15:00 Léo Le Bouter
  2021-03-23 15:48 ` david larsson
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Léo Le Bouter @ 2021-03-23 15:00 UTC (permalink / raw)
  To: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: A proposal for better quality in maintenance of packages by reducing scope
  2021-03-23 15:00 A proposal for better quality in maintenance of packages by reducing scope Léo Le Bouter
@ 2021-03-23 15:48 ` david larsson
  2021-03-23 20:57 ` Christopher Baines
  2021-03-30  8:35 ` Ludovic Courtès
  2 siblings, 0 replies; 4+ messages in thread
From: david larsson @ 2021-03-23 15:48 UTC (permalink / raw)
  To: Léo Le Bouter; +Cc: guix-devel, Guix-devel

On 2021-03-23 16:00, Léo Le Bouter wrote:
> 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

Hi,

Related to your idea on having a relaible updater/refresher; I solved 
some maintenance for myself a while ago by writing a script(1) that I 
used with cuirass which automatically updates packages (both commit and 
hash) to the latest commit for a specified branch, and the same script 
also updates a manifest that is used by a cuirass instance to build 
packages. This way I could install <some-package>-<git-branch> which 
would be continuously updated and built by cuirass, or 
<some-package>-<commit7> when I wanted to stay at a certain upstream 
commit. This is perhaps not the most secure solution, especially not for 
distributing as default, but maybe something similar can be used to help 
maintain the latest version of a subset of packages?

(1) https://gitlab.com/methuselah-0/guix-cigmon/-/tree/master

Best regards,
David


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: A proposal for better quality in maintenance of packages by reducing scope
  2021-03-23 15:00 A proposal for better quality in maintenance of packages by reducing scope Léo Le Bouter
  2021-03-23 15:48 ` david larsson
@ 2021-03-23 20:57 ` Christopher Baines
  2021-03-30  8:35 ` Ludovic Courtès
  2 siblings, 0 replies; 4+ messages in thread
From: Christopher Baines @ 2021-03-23 20:57 UTC (permalink / raw)
  To: Léo Le Bouter; +Cc: guix-devel

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


Léo Le Bouter <lle-bout@zaclys.net> writes:

> 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?

This might be beneficial once there are obvious different groups of
packages, probably falling in to a hierarchy (even just a two level
one). But I don't think that point has been reached yet, so this sounds
like more work for not much benefit.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: A proposal for better quality in maintenance of packages by reducing scope
  2021-03-23 15:00 A proposal for better quality in maintenance of packages by reducing scope Léo Le Bouter
  2021-03-23 15:48 ` david larsson
  2021-03-23 20:57 ` Christopher Baines
@ 2021-03-30  8:35 ` Ludovic Courtès
  2 siblings, 0 replies; 4+ messages in thread
From: Ludovic Courtès @ 2021-03-30  8:35 UTC (permalink / raw)
  To: Léo Le Bouter; +Cc: guix-devel

Hi Léo,

Léo Le Bouter <lle-bout@zaclys.net> skribis:

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

I think most would agree with the general ideas.  What’s more
complicated is the implementation.  What’s “good standards”?  What’s
“realistically”?  How do we tell whether “upstream is cooperative”?
Whether a package is “maintained”?

However, concrete actions we can take is identify shortcomings of
existing tools (I’m glad you reported a bunch of ‘guix refresh’
failures!) and missing tools (a tool that would automatically
refresh/build and push patches to a branch would be great), and work on
them incrementally.

Thanks,
Ludo’.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-03-30  8:36 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-23 15:00 A proposal for better quality in maintenance of packages by reducing scope Léo Le Bouter
2021-03-23 15:48 ` david larsson
2021-03-23 20:57 ` Christopher Baines
2021-03-30  8:35 ` Ludovic Courtès

unofficial mirror of guix-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git