From: Edouard Klein <edou@rdklein.fr>
To: Steve George <steve@futurile.net>
Cc: guix-devel@gnu.org, help-guix@gnu.org
Subject: Re: Guix Days: Patch flow discussion
Date: Tue, 06 Feb 2024 14:27:25 +0100 [thread overview]
Message-ID: <87il3167se.fsf@rdklein.fr> (raw)
In-Reply-To: <10c82db7-6fc6-4fa0-8213-e207fa54db58@futurile.net>
I, for one, would be willing to review patches, hoping that in turn my
patches would be reviewed instead of staying in limbo forever, which is
a drag on me submitting more patches.
Is there a procedure to follow, or do I just start replying "LGTM" to
patch email threads ?
Cheers,
Edouard.
Steve George <steve@futurile.net> writes:
> 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 prev parent reply other threads:[~2024-02-06 13:29 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 ` Edouard Klein [this message]
2024-02-06 13:39 ` Guix Days: Patch flow discussion 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87il3167se.fsf@rdklein.fr \
--to=edou@rdklein.fr \
--cc=guix-devel@gnu.org \
--cc=help-guix@gnu.org \
--cc=steve@futurile.net \
/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.