From: Andreas Enge <andreas@enge.fr>
To: Daniel Littlewood <danielittlewood@gmail.com>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Guix Days: Patch flow discussion
Date: Thu, 29 Feb 2024 19:09:19 +0100 [thread overview]
Message-ID: <ZeDIT_EoEipPDI4h@jurong> (raw)
In-Reply-To: <CAFDSbVdnWfmONFgncAcY=ow=TKUCmGcHr3B7OoZMrZai_ZYAOA@mail.gmail.com>
Hello Dan,
thanks for your thoughts! I think I will restrict my replies to guix-devel
to keep them in one place; the following are just my personal opinions.
Am Thu, Feb 29, 2024 at 03:41:41PM +0000 schrieb Daniel Littlewood:
> Something that is not obvious to me when people refer to reviewing patches, is
> whether this is purely a matter of adding new packages to the main guix
> channel, or of reviewing changes to the system in general, or both. As a
> novice, I can imagine becoming comfortable as a package reviewer much more
> quickly than as a reviewer of core patches to the system.
Both! And indeed what you write is correct, reviewing packages is easier
than services, which is probably easier than other changes. (Personally,
I feel confident only with packages.) Of course then people should only
review things they are comfortable with.
> It's also not obvious to me whether you mean exactly "reviewing a backlog of
> existing patches" or additionally "increasing the amount of patches submitted
> and applied". I feel like both are probably good things but I can't tell what
> you're focussing on exactly. If lots of gems were imported from other repos
> like RubyGems and PyPi, which as I understand it is currently a
> partly-automatic partly-manual process, would that be considered a win? What
> about increasing version coverage among those packages that are covered?
The discussion was about the backlog; in particular also about negative
feelings by contributors of patches that take a long time to be applied.
Of course adding more packages is also a welcome activitiy (but only
makes sense if enough of them are applied in the end...). We concentrated
on "reviewing" to ease the burden of "committers", since reviewing is open
to anybody.
> One point brought up here is about tooling. I wonder whether there is any scope
> for fully automatic review.
I do not think so. Quality is an important aspect of Guix; for instance,
we ask for non-marketing descriptions, which would be difficult to test
automatically. We already have "guix lint", which does some of the work.
And there are fully automated channels such as for CRAN, but which then
are potentially of a lesser quality.
Notice that "easy" packages are also easy to review; most of the time,
there is not much to do about the result of "guix import pypi ...".
Things become more tricky when phases need to be added, to understand
what is going on, and then I usually also look at comments (or criticise
their absence).
> I think some people are just scared off socially by the idea of having to join a
> meeting in order to learn how to do reviews well.
Agreed, there should not be any "having to join a meeting". The idea of
organising one comes from the goal of making the activity more social and
less boring. Apart from that, you can start today and need not wait for
a bug squashing party :)
Andreas
next prev parent reply other threads:[~2024-02-29 18:09 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-05 9:39 Guix Days: Patch flow discussion Steve George
2024-02-05 14:07 ` Leo Famulari
2024-02-05 15:00 ` Tomas Volf
2024-02-05 22:08 ` Wilko Meyer
2024-02-06 11:49 ` Tomas Volf
2024-02-06 12:09 ` Clément Lassieur
2024-02-06 12:53 ` Tomas Volf
2024-02-28 16:05 ` simple service extensions/composizions (Re: Guix Days: Patch flow discussion) Giovanni Biscuolo
2024-02-05 21:57 ` Guix Days: Patch flow discussion Steve George
2024-02-05 15:57 ` Clément Lassieur
2024-02-05 17:10 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-02-05 17:28 ` Clément Lassieur
2024-02-05 18:27 ` Felix Lechner via
2024-02-05 18:50 ` Clément Lassieur
2024-02-05 22:10 ` Steve George
2024-02-05 18:07 ` Hartmut Goebel
2024-02-05 22:29 ` Steve George
2024-02-05 22:31 ` Steve George
2024-02-05 22:31 ` Steve George
2024-02-05 22:31 ` Steve George
2024-02-05 22:31 ` Steve George
2024-02-05 22:31 ` Steve George
2024-02-05 22:31 ` Steve George
2024-02-05 22:32 ` Steve George
2024-02-05 22:32 ` Steve George
2024-02-05 22:33 ` Steve George
2024-02-05 22:50 ` Steve George
2024-02-08 11:59 ` patch workflow without emacs (Was: Re: Guix Days: Patch flow discussion) Efraim Flashner
2024-02-06 13:27 ` Guix Days: Patch flow discussion Edouard Klein
2024-02-06 13:39 ` Steve George
2024-02-08 19:56 ` Skyler Ferris
2024-02-09 16:35 ` Edouard Klein
2024-02-09 16:46 ` Andreas Enge
2024-02-11 10:03 ` Steve George
2024-02-14 21:40 ` Simon Tournier
2024-02-28 17:51 ` Giovanni Biscuolo
2024-02-28 19:21 ` Matt
2024-02-29 15:41 ` Daniel Littlewood
2024-02-29 18:09 ` Andreas Enge [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-02-05 17:21 Suhail
2024-02-05 17:25 ` Vivien Kraus
2024-02-06 11:27 ` Josselin Poiret
[not found] <34679.2393991322$1707153777@news.gmane.org>
2024-02-05 17:36 ` Clément Lassieur
2024-02-05 18:44 Suhail
2024-02-05 19:59 ` Hartmut Goebel
2024-02-06 11:14 ` Josselin Poiret
2024-02-05 18:51 Suhail
2024-02-06 16:51 ` Steve George
2024-02-05 19:33 Andy Tai
2024-02-05 20:50 ` Clément Lassieur
2024-02-06 7:58 ` Andy Tai
[not found] <65c12e7e.0c0a0220.d7729.823cSMTPIN_ADDED_BROKEN@mx.google.com>
2024-02-05 19:52 ` Felix Lechner via
2024-02-05 21:45 Suhail
2024-02-06 19:42 Suhail
2024-02-06 19:47 Suhail
2024-02-06 20:00 Suhail
2024-02-07 13:41 ` Josselin Poiret
2024-02-07 13:46 ` Josselin Poiret
2024-02-11 17:24 ` Vagrant Cascadian
2024-02-22 5:42 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-02-11 20:04 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-02-11 20:21 ` Clément Lassieur
2024-02-11 20:39 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-02-11 22:08 ` Clément Lassieur
2024-02-12 10:35 ` Josselin Poiret
2024-02-12 11:19 ` Clément Lassieur
2024-02-12 15:57 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-02-13 9:31 ` Josselin Poiret
2024-02-13 14:30 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-02-14 9:21 ` Josselin Poiret
2024-02-07 14:30 ` Clément Lassieur
2024-02-07 20:18 ` Ricardo Wurmus
2024-02-08 2:39 ` Kyle Meyer
2024-02-11 16:38 ` Maxim Cournoyer
2024-02-14 15:48 ` Simon Tournier
2024-02-15 11:07 ` Josselin Poiret
2024-02-15 12:45 ` Simon Tournier
2024-02-15 11:45 ` Clément Lassieur
2024-02-15 11:51 ` Clément Lassieur
2024-02-15 15:32 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-02-15 17:19 ` Simon Tournier
2024-02-16 14:27 ` Maxim Cournoyer
2024-02-15 13:06 ` Simon Tournier
2024-02-15 17:24 ` Clément Lassieur
2024-02-15 18:40 ` Simon Tournier
2024-02-15 22:08 ` Clément Lassieur
2024-03-01 22:04 ` Attila Lendvai
2024-02-16 14:25 ` Maxim Cournoyer
2024-02-06 21:01 Suhail
[not found] <35786.5440238797$1707248619@news.gmane.org>
2024-02-16 10:56 ` Clément Lassieur
2024-02-16 11:03 ` Andreas Enge
2024-02-16 11:28 ` Clément Lassieur
2024-02-16 12:06 ` Christopher Baines
2024-02-18 2:31 Suhail
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=ZeDIT_EoEipPDI4h@jurong \
--to=andreas@enge.fr \
--cc=danielittlewood@gmail.com \
--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 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.