From: Steve George <steve@futurile.net>
To: guix-devel@gnu.org
Cc: help-guix@gnu.org
Subject: Guix Days: Patch flow discussion
Date: Mon, 5 Feb 2024 09:39:21 +0000 [thread overview]
Message-ID: <10c82db7-6fc6-4fa0-8213-e207fa54db58@futurile.net> (raw)
Hi,
Our goal for the discussion:
How do we double the number of patches that are *reviewed* and
*applied* to Guix in the next six months?
Patch flow is a pipeline, to change it we could:
a. Increase the number of committers - more people to do the
work
b. Increase the efficiency of existing committers
c. Open the gates by decreasing the quality expected from patches
We essentially decided to focus our discussion on (b). We looked at
things that 'hinder' and 'help' patch review:
Hinders
========
- All our patch reviewers are volunteers doing it in their spare time.
- For a volunteer reviewing someone else's work is not very rewarding,
most would prefer to use that precious time to scratch their own itch.
- Can feel like an Sisyphean task: no matter how many patches someone
reviews there are more, exacerbated by the number of Guix packages.
- Sense of responsibility: the minute that a reviewer looks at the patch
they are now stuck with it
- Repetitive and boring: often patches have minor issues, but it's the
same sorts of issues time and time again.
- Risk of negative social interaction: having to tell someone that their
patch is incorrect, or that their contribution cannot be used is
difficult and draining. Some people felt it was better to say nothing,
rather than to respond to a patch.
Helps
======
This led us to the focus on the fact that **reviewing and applying
patches can be different people**
We looked for ideas to create more reviewers, make reviewing easier and
more fun:
- Share in the work
--------------------
1. encourage new reviewers to step forward - making it more known that
reviewing patches helps to get them applied. Anyone can review patches.
2. create directed 'how-to' documentation for reviewing and connect it
to QA so that 'new reviewers' know what to do
3. create documentation about 'when' and 'how' it's appropriate to send
a 'v2' version of a patch so that the QA system builds and accepts it.
Sometimes, patches rot because non-committers don't want to be seen as
'stealing' someone's work with a v2 patch - but making the small changes
and resubmitting to QA is what is required.
4. Pay someone else to do it. Noted but out of scope.
5. Remove old packages overhead. Old untouched packages create mental
overhead, and make the task of maintaining the repository in a good
state more difficult. We could remove old 'untouched' packages and ones
that no-longer compile. We have methods to hide and notify.
- Make it more fun
-------------------
1. do online sessions around reviews, some sprints or pairing - both
social and a way to spread skills
2. find ways to recognise and appreciate reviewers - 'reviewer of the month'
3. make it a game - we could have a 'Guix London' vs 'Guix Paris' leader
board for reviews. Make it a group goal 'can we beat januarys reviews
number'
4. create some graphs / leaderboard so we know how many patches are
being reviewed and we can recognise the contribution
- Automate it away
-------------------
1. Chris is continuing to try and automate away the boring work -
general agreement in the group that QA has made a lot of difference.
2. general discussion about create a 'guix review' command (Nix has one)
which would download a branch with the appropriate patch and build it
locally. This is for instances where some adjustment is needed or to
check a build. While this can be done today, it's a number of steps and
quite involved.
Agreed Actions
==============
* [Chris]: continuing his work to improve QA automation. Implication was
we'll need some reports / graphs - but these were not discussed in detail.
* [Futurile]: organise a **patch review online sessions**. To run every
13 days (so it rotates through the week) - for 3 months to see if it has
any traction. Co-ordinate with maintainers so that patches that are
reviewed can be committed
Actions looking for someone - you?
====================================
* Carry forward the 'guix review' command idea
* Write an RFC and discuss the idea of removing older 'bit-rot' packages
* write 'how-to' documentation for reviews and when it's socially
acceptable to do a v2 patch. A checklist-like approach.
If you were in the discussion and I've misrepresented your point, or
forgotten an important aspect please please reply and correct me.
Also, if you would like to help on any of the tasks please email back to
the group so we can all co-ordinate.
Finally, thank-you to everyone who came along and put their shared brain
power to the task - look forward to doing some patch reviews together
online in the coming weeks!
Thanks,
Steve/Futurile
next reply other threads:[~2024-02-05 9:40 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-05 9:39 Steve George [this message]
2024-02-05 14:07 ` Guix Days: Patch flow discussion 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
-- 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
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=10c82db7-6fc6-4fa0-8213-e207fa54db58@futurile.net \
--to=steve@futurile.net \
--cc=guix-devel@gnu.org \
--cc=help-guix@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).