unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Guix Days: Patch flow discussion
@ 2024-02-05  9:39 Steve George
  2024-02-05 14:07 ` Leo Famulari
                   ` (4 more replies)
  0 siblings, 5 replies; 34+ messages in thread
From: Steve George @ 2024-02-05  9:39 UTC (permalink / raw)
  To: guix-devel; +Cc: help-guix

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





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

* Re: Guix Days: Patch flow discussion
  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 21:57   ` Steve George
  2024-02-05 15:57 ` Clément Lassieur
                   ` (3 subsequent siblings)
  4 siblings, 2 replies; 34+ messages in thread
From: Leo Famulari @ 2024-02-05 14:07 UTC (permalink / raw)
  To: Steve George, guix-devel

On Mon, Feb 5, 2024, at 04:39, Steve George wrote:
> 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

Hi George,

It's an important subject and, in my opinion, more important than any technical questions at this stage of the project.

However, I think the question assumes that all contributions should be accepted, and that the entire problem is that we are not accepting them efficiently enough. We should not unconsciously accept this assumption.

Guix can reject contributions, either in a general way (we don't want that type of thing in Guix), or due to specific reasons (the code is not idiomatic, the contributor can't work effectively with the rest of the group, etc).

Leo


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

* Re: Guix Days: Patch flow discussion
  2024-02-05 14:07 ` Leo Famulari
@ 2024-02-05 15:00   ` Tomas Volf
  2024-02-05 22:08     ` Wilko Meyer
  2024-02-05 21:57   ` Steve George
  1 sibling, 1 reply; 34+ messages in thread
From: Tomas Volf @ 2024-02-05 15:00 UTC (permalink / raw)
  To: Leo Famulari; +Cc: Steve George, guix-devel

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

On 2024-02-05 09:07:05 -0500, Leo Famulari wrote:
> However, I think the question assumes that all contributions should be accepted, and that the entire problem is that we are not accepting them efficiently enough. We should not unconsciously accept this assumption.
>
> Guix can reject contributions, either in a general way (we don't want that type of thing in Guix), or due to specific reasons (the code is not idiomatic, the contributor can't work effectively with the rest of the group, etc).

And I believe that is fine and completely within the rights of the committers.
However, in my experience contributing, the issue is not that people explicitly
tell me to go away, but that the patches are just ignored.

I would say that the outcome (for any specific patch) from the proposed "review
session" can very well be patch just being closed, or tagged as "need-more-work"
(or whatever tag is Guix using).

In ideal world, there would always be *some* reaction from the project, even if
that reaction would be "we do not want this change".  Even if it would be just
an auto-close (for the "contributor can't work effectively..." case).

Or, to put it in a different way: The problem is not that too few patches get
merged.  The problem is that too few patches get reviewed.

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

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

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

* Re: Guix Days: Patch flow discussion
  2024-02-05  9:39 Guix Days: Patch flow discussion Steve George
  2024-02-05 14:07 ` Leo Famulari
@ 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 22:10   ` Steve George
  2024-02-05 18:07 ` Hartmut Goebel
                   ` (2 subsequent siblings)
  4 siblings, 2 replies; 34+ messages in thread
From: Clément Lassieur @ 2024-02-05 15:57 UTC (permalink / raw)
  To: Steve George; +Cc: guix-devel, help-guix

Hello,

On Mon, Feb 05 2024, Steve George wrote:

> 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

I don't think reviewers have to be committers.  If a patch is marked as
‘reviewed’ by a non-commiter, another person can just apply the patch
and push.  Although the commiter will take some responsibility in doing
so, and make sure the review was done correctly, it still makes their
work way easier.

My point is that not being committer shouldn't discourage people to
review patches.

Clément


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

* Re: Guix Days: Patch flow discussion
  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 22:10   ` Steve George
  1 sibling, 1 reply; 34+ messages in thread
From: Felix Lechner via Development of GNU Guix and the GNU System distribution. @ 2024-02-05 17:10 UTC (permalink / raw)
  To: Clément Lassieur, Steve George; +Cc: guix-devel, help-guix

Hi Clément,

On Mon, Feb 05 2024, Clément Lassieur wrote:

> I don't think reviewers have to be committers.

How much more evidence does the project need to see in order to realize
that the plan is not working?

I'll spare the list a lengthy analysis of the social dynamics but the
delegation of competency to the bottom is an unsuccessful practice in
many places.

Maintainers must close bugs in service to the public. There is no other
way.

Kind regards
Felix


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

* Re: Guix Days: Patch flow discussion
  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
  0 siblings, 1 reply; 34+ messages in thread
From: Clément Lassieur @ 2024-02-05 17:28 UTC (permalink / raw)
  To: Felix Lechner via Development of GNU Guix and the GNU System distribution.
  Cc: Steve George, Felix Lechner, help-guix

On Mon, Feb 05 2024, Felix Lechner via "Development of GNU Guix and the GNU System distribution." wrote:

> Hi Clément,
>
> On Mon, Feb 05 2024, Clément Lassieur wrote:
>
>> I don't think reviewers have to be committers.
>
> How much more evidence does the project need to see in order to realize
> that the plan is not working?

The best review I've had in years was done by a person who is not a
committer.  I see no evidence here.  And I'm unsure which plan you are
talking about (the plan?).

> I'll spare the list a lengthy analysis of the social dynamics but the
> delegation of competency to the bottom is an unsuccessful practice in
> many places.

What do you mean with "bottom"?

> Maintainers must close bugs in service to the public. There is no other
> way.

Reviewing != Closing


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

* Re: Guix Days: Patch flow discussion
  2024-02-05  9:39 Guix Days: Patch flow discussion Steve George
  2024-02-05 14:07 ` Leo Famulari
  2024-02-05 15:57 ` Clément Lassieur
@ 2024-02-05 18:07 ` Hartmut Goebel
  2024-02-05 22:29   ` Steve George
                     ` (10 more replies)
  2024-02-06 13:27 ` Guix Days: Patch flow discussion Edouard Klein
  2024-02-14 21:40 ` Simon Tournier
  4 siblings, 11 replies; 34+ messages in thread
From: Hartmut Goebel @ 2024-02-05 18:07 UTC (permalink / raw)
  To: guix-devel

Am 05.02.24 um 10:39 schrieb Steve George:
> Hinders 

This list is missing one point - which has been discussed several times 
already without any result:

The current mail-based workflow is too complicated for new and 
occasional committers. This is the main reason I gave up reviewing patches.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |



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

* Re: Guix Days: Patch flow discussion
  2024-02-05 17:28     ` Clément Lassieur
@ 2024-02-05 18:27       ` Felix Lechner via
  2024-02-05 18:50         ` Clément Lassieur
  0 siblings, 1 reply; 34+ messages in thread
From: Felix Lechner via @ 2024-02-05 18:27 UTC (permalink / raw)
  To: Clément Lassieur,
	Felix Lechner via Development of GNU Guix and the GNU System distribution.
  Cc: Steve George, help-guix

On Mon, Feb 05 2024, Clément Lassieur wrote:

> On Mon, Feb 05 2024, Felix Lechner via "Development of GNU Guix and the GNU System distribution." wrote:
>
> I see no evidence here.  And I'm unsure which plan you are talking
> about (the plan?).

Two people can look at the same thing and reach different conclusions. I
see no evidence that large numbers of non-committers are eager to review
patches.

> What do you mean with "bottom"?

I'm sorry to put words into your mouth. I meant to quote an executive at
a bank who explained that strategy to me. The word "bottom" was his and
should have been a quote.

The executive referred to people without the authority to act on behalf
of the group.

I believe Guix would be better off to delegate responsibility (rather
than competency) by handing out commit access more generously but
imposing limits as to the type of changes a person may make.

The honor system will work fine.

> Reviewing != Closing

Maybe they should be the same. Two people looking at a patch (submitter
and committer) are more efficient than three people, i.e. a submitter, a
reviewer, and a committer.

It's one of several bottlenecks at Guix. Another is that committers
should commit what they think is right rather than ask for revised
patches.

Please give authorship to the submitter.

Kind regards
Felix


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

* Re: Guix Days: Patch flow discussion
  2024-02-05 18:27       ` Felix Lechner via
@ 2024-02-05 18:50         ` Clément Lassieur
  0 siblings, 0 replies; 34+ messages in thread
From: Clément Lassieur @ 2024-02-05 18:50 UTC (permalink / raw)
  To: Felix Lechner via
  Cc: Felix Lechner via Development of GNU Guix and the GNU System distribution.,
	Felix Lechner, Steve George

On Mon, Feb 05 2024, Felix Lechner via wrote:

> On Mon, Feb 05 2024, Clément Lassieur wrote:
>
>> On Mon, Feb 05 2024, Felix Lechner via "Development of GNU Guix and the GNU System distribution." wrote:
>>
>> I see no evidence here.  And I'm unsure which plan you are talking
>> about (the plan?).
>
> Two people can look at the same thing and reach different conclusions. I
> see no evidence that large numbers of non-committers are eager to review
> patches.

I believe very few people (commiter or not) are eager to review patches.

>> What do you mean with "bottom"?
>
> I'm sorry to put words into your mouth. I meant to quote an executive at
> a bank who explained that strategy to me. The word "bottom" was his and
> should have been a quote.
>
> The executive referred to people without the authority to act on behalf
> of the group.
>
> I believe Guix would be better off to delegate responsibility (rather
> than competency) by handing out commit access more generously but
> imposing limits as to the type of changes a person may make.
>
> The honor system will work fine.
>
>> Reviewing != Closing
>
> Maybe they should be the same. Two people looking at a patch (submitter
> and committer) are more efficient than three people, i.e. a submitter, a
> reviewer, and a committer.

Committers are trusted, and obviously it takes time to be trusted, so
not everyone can be at once.  Reviewing requires less trust because the
committer can do a quick check that everything is in order before
submitting the patch.

It's less efficient if you compare flows for two patches, but for 1000
patches, it makes it easier to find reviewers, so in the end it's more
efficient.

> It's one of several bottlenecks at Guix. Another is that committers
> should commit what they think is right rather than ask for revised
> patches.

I sometimes update the commit a little bit before pushing, and then
explain what I changed in my email.  But if the changes are big, I often
believe it makes more sense to ask for a v2.

> Please give authorship to the submitter.

I think it's the case?

Cheers,
Clément


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

* Re: Guix Days: Patch flow discussion
  2024-02-05 14:07 ` Leo Famulari
  2024-02-05 15:00   ` Tomas Volf
@ 2024-02-05 21:57   ` Steve George
  1 sibling, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-05 21:57 UTC (permalink / raw)
  To: Leo Famulari, guix-devel

Hi Leo,

On 05/02/2024 14:07, Leo Famulari wrote:
> On Mon, Feb 5, 2024, at 04:39, Steve George wrote:
>> 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
> 
> Hi George,

Just 'Steve' :-)

> It's an important subject and, in my opinion, more important than any technical questions at this stage of the project.
> 
> However, I think the question assumes that all contributions should be accepted, and that the entire problem is that we are not accepting them efficiently enough. We should not unconsciously accept this assumption.
> 
> Guix can reject contributions, either in a general way (we don't want that type of thing in Guix), or due to specific reasons (the code is not idiomatic, the contributor can't work effectively with the rest of the group, etc).
(...)

Today there are 1264 bugs with patches attached to them today [0].

We don't have any stats (that I'm aware of) that show how many patches 
the project reviews and either asks for edits, rejects or applies.

The group - and I hope the minutes reflect this - wanted to maintain the 
current standards. So the discussion of the pipeline focused on how we 
review more patches, and make decisions about them: whether that 
decision is to accept the contribution, ask for more work, or reject it 
as out of scope.

To answer your comment about the 'unconscious' assumptions - my personal 
view is:

* I don't think ALL patches should simply be accepted
* I do think that more patches need to be reviewed and a decision made
* I believe (no evidence) the project is missing out on great 
contributions amongst those 1200+ patches in the tracker
* I believe (no evidence) that potential contributors are put-off by the 
speed of review / lack of clarity

Thanks,

Steve

[0] https://debbugs.gnu.org/rrd/guix-patches.html



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

* Re: Guix Days: Patch flow discussion
  2024-02-05 15:00   ` Tomas Volf
@ 2024-02-05 22:08     ` Wilko Meyer
  2024-02-06 11:49       ` Tomas Volf
  0 siblings, 1 reply; 34+ messages in thread
From: Wilko Meyer @ 2024-02-05 22:08 UTC (permalink / raw)
  To: Tomas Volf; +Cc: Leo Famulari, Steve George, guix-devel


Hi Guix,

Tomas Volf <~@wolfsden.cz> writes:

> Or, to put it in a different way: The problem is not that too few patches get
> merged.  The problem is that too few patches get reviewed.

I'd say that both things stem from the same premise, a disproportion of
available resources to the work that exists. This is not something
specific to Guix as a project, but can be observed in many other
projects as well (I couldn't name one larger free software or open
source project without this issue, but could easily name some where this
applies). The interests of a contributer sending a patch sometimes may
not align with the interests of the project/sometimes may not align with
the interests of commiters and so on. This happens and is a pretty
common reason for contributions being ignored and I see that as somewhat
a default modus operandi in many projects. Especially if available time
is a rather sparse resource.

I'd like to suggest to explicity refer to pragmatic ways forward in
Guixes Contributing manual section that don't rely on the availability
of other peoples (in this case committers/reviewers) time while
empowering contributors to use their changes in a good way if a patch
doesn't make it in/a bug report gets no reaction? Guix offers ways to
use packages outside of Guix proper in a pretty feasible and
maintainable way (manifests, setting up channels), maybe promoting them
as an alternative to having things in guix proper "as soon as possible"
(as that's not the only option to have things in a usable form) would be
beneficial.

-- 
Kind regards,

Wilko Meyer
w@wmeyer.eu


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

* Re: Guix Days: Patch flow discussion
  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 22:10   ` Steve George
  1 sibling, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-05 22:10 UTC (permalink / raw)
  To: Clément Lassieur; +Cc: guix-devel, help-guix

On 05/02/2024 15:57, Clément Lassieur wrote:
> Hello,
> 
> On Mon, Feb 05 2024, Steve George wrote:
> 
>> 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
> 
> I don't think reviewers have to be committers.  If a patch is marked as
> ‘reviewed’ by a non-commiter, another person can just apply the patch
> and push.  Although the commiter will take some responsibility in doing
> so, and make sure the review was done correctly, it still makes their
> work way easier.
> 
> My point is that not being committer shouldn't discourage people to
> review patches.
(...)

Agreed - I put it a bit lower in the notes - clearly managed to bury it :-)

The discussion focused on increasing the number of Reviewers. A reviewer 
can be anyone - they don't need to be a committer.

The purpose of the proposed 'Patch Review' sessions is for contributors 
to come along and review patches together.

Thanks,

Steve




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

* Re: Guix Days: Patch flow discussion
  2024-02-05 18:07 ` Hartmut Goebel
@ 2024-02-05 22:29   ` Steve George
  2024-02-05 22:31   ` Steve George
                     ` (9 subsequent siblings)
  10 siblings, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-05 22:29 UTC (permalink / raw)
  To: h.goebel; +Cc: guix-devel



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

* Re: Guix Days: Patch flow discussion
  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
                     ` (8 subsequent siblings)
  10 siblings, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-05 22:31 UTC (permalink / raw)
  To: h.goebel; +Cc: guix-devel



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

* Re: Guix Days: Patch flow discussion
  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
                     ` (7 subsequent siblings)
  10 siblings, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-05 22:31 UTC (permalink / raw)
  To: h.goebel; +Cc: guix-devel



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

* Re: Guix Days: Patch flow discussion
  2024-02-05 18:07 ` Hartmut Goebel
                     ` (3 preceding siblings ...)
  2024-02-05 22:31   ` Steve George
@ 2024-02-05 22:31   ` Steve George
  2024-02-05 22:31   ` Steve George
                     ` (5 subsequent siblings)
  10 siblings, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-05 22:31 UTC (permalink / raw)
  To: h.goebel; +Cc: guix-devel



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

* Re: Guix Days: Patch flow discussion
  2024-02-05 18:07 ` Hartmut Goebel
                     ` (2 preceding siblings ...)
  2024-02-05 22:31   ` Steve George
@ 2024-02-05 22:31   ` Steve George
  2024-02-05 22:31   ` Steve George
                     ` (6 subsequent siblings)
  10 siblings, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-05 22:31 UTC (permalink / raw)
  To: h.goebel; +Cc: guix-devel



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

* Re: Guix Days: Patch flow discussion
  2024-02-05 18:07 ` Hartmut Goebel
                     ` (4 preceding siblings ...)
  2024-02-05 22:31   ` Steve George
@ 2024-02-05 22:31   ` Steve George
  2024-02-05 22:31   ` Steve George
                     ` (4 subsequent siblings)
  10 siblings, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-05 22:31 UTC (permalink / raw)
  To: h.goebel; +Cc: guix-devel



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

* Re: Guix Days: Patch flow discussion
  2024-02-05 18:07 ` Hartmut Goebel
                     ` (5 preceding siblings ...)
  2024-02-05 22:31   ` Steve George
@ 2024-02-05 22:31   ` Steve George
  2024-02-05 22:32   ` Steve George
                     ` (3 subsequent siblings)
  10 siblings, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-05 22:31 UTC (permalink / raw)
  To: h.goebel; +Cc: guix-devel



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

* Re: Guix Days: Patch flow discussion
  2024-02-05 18:07 ` Hartmut Goebel
                     ` (6 preceding siblings ...)
  2024-02-05 22:31   ` Steve George
@ 2024-02-05 22:32   ` Steve George
  2024-02-05 22:32   ` Steve George
                     ` (2 subsequent siblings)
  10 siblings, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-05 22:32 UTC (permalink / raw)
  To: h.goebel; +Cc: guix-devel



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

* Re: Guix Days: Patch flow discussion
  2024-02-05 18:07 ` Hartmut Goebel
                     ` (7 preceding siblings ...)
  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
  10 siblings, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-05 22:32 UTC (permalink / raw)
  To: h.goebel; +Cc: guix-devel



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

* Re: Guix Days: Patch flow discussion
  2024-02-05 18:07 ` Hartmut Goebel
                     ` (8 preceding siblings ...)
  2024-02-05 22:32   ` Steve George
@ 2024-02-05 22:33   ` Steve George
  2024-02-05 22:50   ` Steve George
  10 siblings, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-05 22:33 UTC (permalink / raw)
  To: h.goebel; +Cc: guix-devel



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

* Re: Guix Days: Patch flow discussion
  2024-02-05 18:07 ` Hartmut Goebel
                     ` (9 preceding siblings ...)
  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
  10 siblings, 1 reply; 34+ messages in thread
From: Steve George @ 2024-02-05 22:50 UTC (permalink / raw)
  To: h.goebel; +Cc: guix-devel

Hi Hartmut,

Apologies, my reply-to went a bit mad and I sent you empty emails :-(

You said:

> The current mail-based workflow is too complicated for new and 
> occasional committers. This is the main reason I gave up reviewing patches.
>

In the case of *reviewing patches* can you give some examples of:

1. Some patches from others you reviewed?
2. The steps you went through to undertake that review?

If for example, you started to review a simple update to a package how do you 
aproach it?

It would be great to hear directly from someone doing 'reviewing' on the 
specifics. Apologies, if this is going over old ground.

Thanks,

Steve


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

* Re: Guix Days: Patch flow discussion
  2024-02-05 22:08     ` Wilko Meyer
@ 2024-02-06 11:49       ` Tomas Volf
  2024-02-06 12:09         ` Clément Lassieur
  0 siblings, 1 reply; 34+ messages in thread
From: Tomas Volf @ 2024-02-06 11:49 UTC (permalink / raw)
  To: Wilko Meyer; +Cc: Leo Famulari, Steve George, guix-devel

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

On 2024-02-05 23:08:29 +0100, Wilko Meyer wrote:
> Guix offers ways to use packages outside of Guix proper in a pretty feasible
> and maintainable way (manifests, setting up channels), maybe promoting them as
> an alternative to having things in guix proper "as soon as possible" (as
> that's not the only option to have things in a usable form) would be
> beneficial.

I would just like to point out that while this applies to packages, it is bit
more complicated for services and other core parts of the Guix.  Combined with
the fact that Guix severely restricts what workflow model can forks use (e.g.
merge not being possible if the fork should be authenticated), maintaining
non-package modifications for longer periods of time can be a hassle.

So it could be beneficial to put some though into that as well.

Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

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

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

* Re: Guix Days: Patch flow discussion
  2024-02-06 11:49       ` Tomas Volf
@ 2024-02-06 12:09         ` Clément Lassieur
  2024-02-06 12:53           ` Tomas Volf
  0 siblings, 1 reply; 34+ messages in thread
From: Clément Lassieur @ 2024-02-06 12:09 UTC (permalink / raw)
  To: Wilko Meyer; +Cc: Leo Famulari, Steve George, guix-devel

On Tue, Feb 06 2024, Tomas Volf wrote:

> On 2024-02-05 23:08:29 +0100, Wilko Meyer wrote:
>> Guix offers ways to use packages outside of Guix proper in a pretty feasible
>> and maintainable way (manifests, setting up channels), maybe promoting them as
>> an alternative to having things in guix proper "as soon as possible" (as
>> that's not the only option to have things in a usable form) would be
>> beneficial.
>
> I would just like to point out that while this applies to packages, it is bit
> more complicated for services and other core parts of the Guix.  Combined with
> the fact that Guix severely restricts what workflow model can forks use (e.g.
> merge not being possible if the fork should be authenticated), maintaining
> non-package modifications for longer periods of time can be a hassle.

Hi!  Why is it more complicated with services?  You don't need forks at
all to use packages and services outside of Guix proper.


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

* Re: Guix Days: Patch flow discussion
  2024-02-06 12:09         ` Clément Lassieur
@ 2024-02-06 12:53           ` Tomas Volf
  0 siblings, 0 replies; 34+ messages in thread
From: Tomas Volf @ 2024-02-06 12:53 UTC (permalink / raw)
  To: Clément Lassieur; +Cc: Wilko Meyer, Leo Famulari, Steve George, guix-devel

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

On 2024-02-06 13:09:15 +0100, Clément Lassieur wrote:
> Hi!  Why is it more complicated with services?  You don't need forks at
> all to use packages and services outside of Guix proper.

For packages we have transformations, or I can just inherit.  But I am not aware
of such option for services (is there anything?).

Example: For long time the connman-configuration did not support a way to
provide a configuration file (well, it still does not but that is not the
point).  But I needed it.  So, what options I had?

1. Copy&paste the definition (-configuration, -service-type, ...?) into my
   system configuration and modify it.
2. Modify it in-place in my fork.

I tried 1. first, but keeping it up-to-date proved annoying, having zero support
from git.  Since I already made my fork (due to #65002, which just is not
possible to do outside Guix repository), I later switched to 2. and it worked
well, so I prefer that approach now.

I agree there is no issue for new packages nor new services, I should have
clarified that in my original message.

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

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

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

* Re: Guix Days: Patch flow discussion
  2024-02-05  9:39 Guix Days: Patch flow discussion Steve George
                   ` (2 preceding siblings ...)
  2024-02-05 18:07 ` Hartmut Goebel
@ 2024-02-06 13:27 ` Edouard Klein
  2024-02-06 13:39   ` Steve George
  2024-02-14 21:40 ` Simon Tournier
  4 siblings, 1 reply; 34+ messages in thread
From: Edouard Klein @ 2024-02-06 13:27 UTC (permalink / raw)
  To: Steve George; +Cc: guix-devel, help-guix

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


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

* Re: Guix Days: Patch flow discussion
  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
  0 siblings, 1 reply; 34+ messages in thread
From: Steve George @ 2024-02-06 13:39 UTC (permalink / raw)
  To: Edouard Klein; +Cc: guix-devel, help-guix


Hi Edouard,

On  6 Feb, Edouard Klein wrote:
> 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 ?

Starting to review patches would be brilliant.

I agreed to organise some 'patch review' online sessions in the next couple of 
weeks. 

Organising a basic process is a good topic for that online session. For 
example, elsewhere in the thread someone mentions some tags we could use 
consistently so maintainers can find patches that have been reviewed easily. It 
would be great to agree those - try them for a bit - and document them in a 
'howto' so that everyone uses the same process.

Steve




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

* patch workflow without emacs (Was: Re: Guix Days: Patch flow discussion)
  2024-02-05 22:50   ` Steve George
@ 2024-02-08 11:59     ` Efraim Flashner
  0 siblings, 0 replies; 34+ messages in thread
From: Efraim Flashner @ 2024-02-08 11:59 UTC (permalink / raw)
  To: Steve George; +Cc: h.goebel, guix-devel

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

On Mon, Feb 05, 2024 at 10:50:36PM +0000, Steve George wrote:
> Hi Hartmut,
> 
> Apologies, my reply-to went a bit mad and I sent you empty emails :-(
> 
> You said:
> 
> > The current mail-based workflow is too complicated for new and 
> > occasional committers. This is the main reason I gave up reviewing patches.
> >
> 
> In the case of *reviewing patches* can you give some examples of:
> 
> 1. Some patches from others you reviewed?
> 2. The steps you went through to undertake that review?
> 
> If for example, you started to review a simple update to a package how do you 
> aproach it?
> 
> It would be great to hear directly from someone doing 'reviewing' on the 
> specifics. Apologies, if this is going over old ground.

First step is choosing a package to review. I normally start with ones
that are emailed to me directly as part of the rust-team.

I now have an email thread with between 20 and 150 patches to review. (I
start by looking through some of them manually to see if they look like
they're following conventions, ie: 1 change per patch. Assuming they
generally look good,) I start with the first patch and, from mutt, I
pipe the patch to 'cd ~/workspace/guix; git am -S -s'. I then compare
the commit message to the contents of the patch, looking at it in 'tig',
a TUI git interface, and will adjust the patch and/or the commit message
as necessary. Then I try to build the package(s) changed by the patch
set so far. When I'm happy with how it looks I'll pipe the next patch
from mutt to check out.

Once I reach the end of a patch series, or after a bunch of patches,
I'll look through the set I've applied to make sure I'm still happy with
them as a whole (update the package and then remove it?) and then
continue on.  At the end, when I'm happy with it, I'll reply to the
first or last email, detail a bit what changes I've made, and tell them
that I've applied the patches. I then save the email in my drafts folder
and move on to the next patch series I'm going to look at.  At the end,
after rebasing everything on top of wherever the branch moved to while I
was working, I'll push my branch to Savannah and then send off the
emails.

If I come across a patch that I'd like changes to before committing I'll
either add them inline ('v' in mutt to see the parts of the email,
choose the part with the patch, 'g' to reply-all, and then add them
inline), or I'll apply it and then reply to the original email with the
diff ('git diff -p > ~/changes-to-XXXX.diff', attach in reply email) and
some text in the header about the changes. I then throw out my local
changes since they're either where I can recover it from the email or in
my git stash.

If I choose a package from qa.guix.gnu.org to review I'll pick one and
note the number. I go to my checkout, 'git fetch --all' to refresh my
checkouts¹, open it with tig, switch to the branches view (with 'r'),
find the patchset (guix-patches/issue-XXXXX), and then with 'C' I'll
cherry-pick all the patches from the patchset in one go. I then look
them over one at at time in tig like above, and I'll make any changes to
either 'squash' or 'fixup' onto specific patches later when I go over it
with 'git rebase -i'.

Some notes: I've never figured out how to use emacs, much less emacs and
debbugs. My only interaction with debbugs is to open or close bugs; I
do not know how to look at user tags, or any other tags, in debbugs,
although I would guess that it might be possible from the web frontend.
Similarly, I don't know if a bug has been closed by someone else, I just
assume it to be so when a patch is applied or if I see it said so in an
email. I use vim-fugitive (and editorconfig I guess) as my only plugin
for working with git.

¹ https://git.guix-patches.cbaines.net/git/guix-patches is the location
where the patchsets are stored in a git repo

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

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

* Re: Guix Days: Patch flow discussion
  2024-02-06 13:39   ` Steve George
@ 2024-02-08 19:56     ` Skyler Ferris
  2024-02-09 16:35       ` Edouard Klein
  0 siblings, 1 reply; 34+ messages in thread
From: Skyler Ferris @ 2024-02-08 19:56 UTC (permalink / raw)
  To: Steve George, Edouard Klein; +Cc: guix-devel, help-guix

On 2/6/24 05:39, Steve George wrote:
> I agreed to organise some 'patch review' online sessions in the next couple of
> weeks.
>
> Organising a basic process is a good topic for that online session. For
> example, elsewhere in the thread someone mentions some tags we could use
> consistently so maintainers can find patches that have been reviewed easily. It
> would be great to agree those - try them for a bit - and document them in a
> 'howto' so that everyone uses the same process.
Have these been announced somewhere yet (eg, with url & exact time)? If 
not will being subscribed to the help-guix list and/or checking the Guix 
blog be sufficient to receive notification? As someone who has sent 
patches in the past and intends to continue sending more in the future, 
I'd like to do my part to keep the project in a good state. However, I 
am new to interacting with large FLOSS projects so I'm nervous about 
causing more problems than I solve if I just start doing things.



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

* Re: Guix Days: Patch flow discussion
  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
  0 siblings, 2 replies; 34+ messages in thread
From: Edouard Klein @ 2024-02-09 16:35 UTC (permalink / raw)
  To: Skyler Ferris; +Cc: Steve George, guix-devel, help-guix


Skyler Ferris <skyvine@protonmail.com> writes:

> On 2/6/24 05:39, Steve George wrote:
>> I agreed to organise some 'patch review' online sessions in the next couple of
>> weeks.
>>
>> Organising a basic process is a good topic for that online session. For
>> example, elsewhere in the thread someone mentions some tags we could use
>> consistently so maintainers can find patches that have been reviewed easily. It
>> would be great to agree those - try them for a bit - and document them in a
>> 'howto' so that everyone uses the same process.
> Have these been announced somewhere yet (eg, with url & exact time)? If
> not will being subscribed to the help-guix list and/or checking the Guix
> blog be sufficient to receive notification? As someone who has sent
> patches in the past and intends to continue sending more in the future,
> I'd like to do my part to keep the project in a good state. However, I
> am new to interacting with large FLOSS projects so I'm nervous about
> causing more problems than I solve if I just start doing things.

Same here.


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

* Re: Guix Days: Patch flow discussion
  2024-02-09 16:35       ` Edouard Klein
@ 2024-02-09 16:46         ` Andreas Enge
  2024-02-11 10:03         ` Steve George
  1 sibling, 0 replies; 34+ messages in thread
From: Andreas Enge @ 2024-02-09 16:46 UTC (permalink / raw)
  To: Edouard Klein; +Cc: Skyler Ferris, Steve George, guix-devel, help-guix

Hello,

Am Fri, Feb 09, 2024 at 05:35:44PM +0100 schrieb Edouard Klein:
> Am Thu, Feb 08, 2024 at 07:56:48PM +0000 schrieb Skyler Ferris:
> > I'd like to do my part to keep the project in a good state. However, I
> > am new to interacting with large FLOSS projects so I'm nervous about
> > causing more problems than I solve if I just start doing things.
> Same here.

no need to be nervous! I would suggest to just start somewhere and learn
by doing. For patches, anyway the committer takes the final responsibility;
so if you can just add, for instance, "I use this package and it works for
me" this will be a useful point.

And do not be afraid to make mistakes; I have been taking part in Guix for
a long time now, and of course make mistakes from time to time. That
happens, and they can be corrected if they occur. What I find important
is to be upfront about them, and to ask for help if needed.

Andreas



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

* Re: Guix Days: Patch flow discussion
  2024-02-09 16:35       ` Edouard Klein
  2024-02-09 16:46         ` Andreas Enge
@ 2024-02-11 10:03         ` Steve George
  1 sibling, 0 replies; 34+ messages in thread
From: Steve George @ 2024-02-11 10:03 UTC (permalink / raw)
  To: Edouard Klein, Skyler Ferris; +Cc: guix-devel, help-guix

On  9 Feb, Edouard Klein wrote:
> 
> Skyler Ferris <skyvine@protonmail.com> writes:
> 
> > On 2/6/24 05:39, Steve George wrote:
> >> I agreed to organise some 'patch review' online sessions in the next couple of
> >> weeks.
> >>
> >> Organising a basic process is a good topic for that online session. For
> >> example, elsewhere in the thread someone mentions some tags we could use
> >> consistently so maintainers can find patches that have been reviewed easily. It
> >> would be great to agree those - try them for a bit - and document them in a
> >> 'howto' so that everyone uses the same process.
> > Have these been announced somewhere yet (eg, with url & exact time)? If
> > not will being subscribed to the help-guix list and/or checking the Guix
> > blog be sufficient to receive notification? As someone who has sent
> > patches in the past and intends to continue sending more in the future,
> > I'd like to do my part to keep the project in a good state. However, I
> > am new to interacting with large FLOSS projects so I'm nervous about
> > causing more problems than I solve if I just start doing things.
> 
> Same here.
>

Hi Skyler & Edouard - you haven't missed an announcement :-) I'll get it organised next week and will mail out here - plus I'll email you both directly as you've both shown interest.

Thanks,

Steve / Futurile







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

* Re: Guix Days: Patch flow discussion
  2024-02-05  9:39 Guix Days: Patch flow discussion Steve George
                   ` (3 preceding siblings ...)
  2024-02-06 13:27 ` Guix Days: Patch flow discussion Edouard Klein
@ 2024-02-14 21:40 ` Simon Tournier
  4 siblings, 0 replies; 34+ messages in thread
From: Simon Tournier @ 2024-02-14 21:40 UTC (permalink / raw)
  To: Steve George, guix-devel; +Cc: help-guix

Hi Steve,

  ( On a side note, the triage of old bugs is a similar problem.  They
    are easy to find [2], read, check and send an email to
    12345@debbugs.gnu.org does not appear to me an issue with any tool.
    
    For what it is worth and without any willing of being harsh, I am
    able to count the people doing this boring task.

    What is hard to solve is the incentives for doing the boring, but
    necessary, collective tasks.

    Bah the usual problem of lengthy discussions with roommates in any
    shared apartment: who clean the bathroom? :-) )


On lun., 05 févr. 2024 at 09:39, Steve George <steve@futurile.net> wrote:

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

Thanks for these notes and leading the session.  On my side, it was a
fruitful discussion.

Well, let me try to quickly summarize my conclusion of the session:

 1. We have a social/organisational problem.

 2. We have some tooling annoyances.



The easy first: #2 about tools.  The email workflow is often cited as
part of the issue.  That’s a false-problem, IMHO.

Projects that use PR/MR workflow have the same problem.  For instance,
Julia [1] has 896 open PR.  On my browser, it means 36 pages so if I go
to – 25 PRs per page – the still open submitted PRs:

   + the 6th page:  around Sept.2023 and Oct. 2023
   + the 12th page: around Apr. 2023 and Mar. 2023
   + the 18th page: around Jul. 2022 and Mar. 2022
   + the 24th page: around Jun. 2021 and May  2021
   + the 30th page: around Mar. 2020 and Oct. 2019
   + the 36th page: around Mar. 2017 and May. 2014

Obviously, an example is not a proof or an evidence.  It is just a
first clue. :-)

I will not speak about the channel ’nonguix’ but it gives another
clue.

That said, for sure, the tools need more love.  Thanks all the people
for all hard work over the years in this area – no name, you know, I
fear to forget someone. ;-)

So, yeah we need to smooth the technical burden for reviewing in order
to focus on the review itself.

To be clear, the email workflow might add burden on submitter side but I
am doubtful it is really part of the bottleneck for reviewing and
pushing submissions.


Although the tools might add some unnecessary friction, the net of the
issue is IMHO #1: reviewing is just boring and time-consuming.

Who feel accountable?  And for what?  That’s the question, IMHO.

If the number of submission is doubled, how do we increase the number of
people that feel enough accountable for doing the boring work?

  ( Maybe accountable is not the correct word.  Obligation neither.
    Well the kind of feeling that is okish if you skip the task but you
    know it will be better if you do it. )


Well, the difficult part is not pressing some buttons for merging and
pushing – whatever the tools or workflow.  The difficult part is to
scrutinize the submission.

I think the bottleneck is not the number of people able to push.
Instead, I think the bottleneck is the number of people confident with
the change for then pushing it.

The question is thus: how to build this confidence?


Look, when a committer has some free-time, most of the time, what is the
process: take first the “easy“ submissions for committing them – from
trivial updates to simple updates.  If free-time remains, then engage
with more “complex” submissions… ah no more free-time. :-)

Why starting by the “easy” submission?  Because it is less boring and
time-consuming; somehow it is easier to feel confident with that sort of
change for pushing it.

As a rule of thumb, about the time it takes – on average –, the order of
magnitude for reviewing is similar as the one for submitting.  Well,
from my experience and although I never did stats. :-)


All in all, I see two paths to move forward:

i) Non-committers can help.  On two fronts:

   + Answer to submitter with the changes for being compliant with Guix
     standards.
   
   + Follow-up on patches already commented but without an updated
     revision: upgrade the re-roll count by sending this revision.

     It eases for merging if I do not have to make many tiny edits
     myself.

ii) Create more teams or at least more people should commit to be part
    of a team and help in reviewing what they know.

    For instance, since Sept. (167 days ago) I have been CC in 108
    patches submissions.  Most of them are from ’core’ team that I would
    qualify as “complex”. :-)

    Many patches assigned to ’core’ team are sent by committers.  The
    issue is not being a committer or not.  Instead, being more eyes
    commenting would increase the confidence.  Thus it would reduce the
    workload.

    That’s the same for any team, IMHO.
    
    And I do not speak about patches that are not assigned to any team.


Somehow, we need to think how people would feel “accountable” for doing
the collective tasks with low, no direct or personal reward.

As with many non-technical topics, it is not easy.  Because it is a
collective journey not clearly identified – and not a kind of
reproducible bug to fix, even the tougher.

Last, the manual says:

    « As a rule of thumb, a contributor should have accumulated
      fifty (50) reviewed commits to be considered as a committer
      and have sustained their activity in the project for at least
      6 months. »

So if people are willing to take more responsibility to help the
project…


Well, while writing that I could have give a look to patches… ;-)

Cheers,
simon


1: https://github.com/JuliaLang/julia
2: https://issues.guix.gnu.org/forgotten



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

end of thread, other threads:[~2024-02-15  9:54 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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-05 21:57   ` 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

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