unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
* Re: Guix Days: Patch flow discussion
@ 2024-02-18  2:31 Suhail
  0 siblings, 0 replies; 27+ messages in thread
From: Suhail @ 2024-02-18  2:31 UTC (permalink / raw)
  To: Clément Lassieur
  Cc: Suhail, Steve George, Edouard Klein, guix-devel, help-guix

Clément Lassieur <clement@lassieur.org> writes:

>> It seems on the [dev manual] we already have "reviewed-looks-good"
>> documented.  Thus, I'd like to propose the below *mutually exclusive*
>> Debbugs tag set:
>>
>> - "not-yet-reviewed" :: automatically set for all submissions
>> - "reviewed-needs-fix" :: set explicitly by the reviewer
>> - "needs-another-review" :: automatically set if there's a revised
>>   patch, unless "not-yet-reviewed" (in which case no change)
>> - "reviewed-looks-good" :: set explicitly by the reviewer
>
> Would it makes sense to have a "does-not-apply" tag too?
>
> I believe that would help sorting old those old patches that don't apply
> anymore.

Agreed.  A "does-not-apply" tag would be helpful.  This tag would be
explicitly applied, either by the QA mechanism or a reviewer.

Assuming there aren't any objections to these tags, what are the next
steps?  If my understanding of Debbugs Usertags is correct it seems we
can simply start using them?  Though noting the above in the manual
would be helpful.  However, that still leaves open the issue of how the
automated setting of tags is accomplished.

Thoughts?

-- 
Suhail



^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: Guix Days: Patch flow discussion
@ 2024-02-06 19:47 Suhail
  0 siblings, 0 replies; 27+ messages in thread
From: Suhail @ 2024-02-06 19:47 UTC (permalink / raw)
  To: Steve George
  Cc: Suhail, Felix Lechner, Clément Lassieur,
	Guix-devel mailing list, Help-Guix mailing list

Steve George <steve@futurile.net> writes:

> The general opinion seemed to be, that it was better to fix small
> issues and commit the change for new users, so they had the
> satisfaction of their contribution making it into the repository. One
> proposal was to do the 'fix', and to then reply back to the bug with a
> diff - showing what was done.

I see.  Thank you for sharing.  I believe being more didactic with "new
users" would be good for the community.

-- 
Suhail



^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: Guix Days: Patch flow discussion
@ 2024-02-06 19:42 Suhail
  0 siblings, 0 replies; 27+ messages in thread
From: Suhail @ 2024-02-06 19:42 UTC (permalink / raw)
  To: Steve George; +Cc: Edouard Klein, guix-devel, help-guix

Steve George <steve@futurile.net> writes:

> elsewhere in the thread someone mentions some tags we could use
> consistently so maintainers can find patches that have been reviewed
> easily.

It seems on the [dev manual] we already have "reviewed-looks-good"
documented.  Thus, I'd like to propose the below *mutually exclusive*
Debbugs tag set:

- "not-yet-reviewed" :: automatically set for all submissions
- "reviewed-needs-fix" :: set explicitly by the reviewer
- "needs-another-review" :: automatically set if there's a revised
  patch, unless "not-yet-reviewed" (in which case no change)
- "reviewed-looks-good" :: set explicitly by the reviewer

In addition to the above, it might also help for there to be an
additional tag of "might-not-need-review" (or simpler,
"review-not-needed") which gets automatically set, provided we implement
a way to label some changes (for some packages) as being "trivial enough
that they're okay as long as build succeeds".

On a related note, is it possible for a reviewer who isn't a committer
to set debbugs tags?

[dev manual]: <https://guix.gnu.org/en/manual/devel/en/html_node/Debbugs-Usertags.html>

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

In addition to documenting the tags in the "Debbugs Usertags" section of
the manual, it would help for there to be a "howto" which focuses more
on the transition between the tags (i.e., the contribution workflow).

-- 
Suhail



^ permalink raw reply	[flat|nested] 27+ messages in thread
[parent not found: <65c12e7e.0c0a0220.d7729.823cSMTPIN_ADDED_BROKEN@mx.google.com>]
* Re: Guix Days: Patch flow discussion
@ 2024-02-05 18:51 Suhail
  2024-02-06 16:51 ` Steve George
  0 siblings, 1 reply; 27+ messages in thread
From: Suhail @ 2024-02-05 18:51 UTC (permalink / raw)
  To: Felix Lechner
  Cc: Clément Lassieur, Steve George, Guix-devel mailing list,
	Help-Guix mailing list

Felix Lechner via <help-guix@gnu.org> writes:

> Another is that committers should commit what they think is right
> rather than ask for revised patches.

I could be mistaken, but I believe this does happen today at least some
of the time.  Is your position that

1. this never happens today and thus, should happen some times when
   warranted.  Or that,

2. it happens far too rarely today, and should happen more often. Or
   that,

3. committers should never ask for revisions?

-- 
Suhail



^ permalink raw reply	[flat|nested] 27+ messages in thread
* Guix Days: Patch flow discussion
@ 2024-02-05  9:39 Steve George
  2024-02-05 15:57 ` Clément Lassieur
                   ` (2 more replies)
  0 siblings, 3 replies; 27+ 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] 27+ messages in thread

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

Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <35786.5440238797$1707248619@news.gmane.org>
2024-02-16 10:56 ` Guix Days: Patch flow discussion 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
  -- strict thread matches above, loose matches on Subject: below --
2024-02-06 19:47 Suhail
2024-02-06 19:42 Suhail
     [not found] <65c12e7e.0c0a0220.d7729.823cSMTPIN_ADDED_BROKEN@mx.google.com>
2024-02-05 19:52 ` Felix Lechner via
2024-02-05 18:51 Suhail
2024-02-06 16:51 ` Steve George
2024-02-05  9:39 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-06 13:27 ` 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

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