guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notes from discussion on Quality Assurance from the 10 Years of Guix


From: Tanguy LE CARROUR
Subject: Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event
Date: Wed, 05 Oct 2022 16:01:40 +0200
User-agent: alot/0.10

Hi Chris,


Quoting Christopher Baines (2022-09-18 17:55:30)
> Here are some notes I took during the discussion on patch review/quality
> assurance at the 10 Years of Guix event.

Thanks for the notes!

After months not contributing, today, I've started contributing patches
again!
Seems like I've forgotten everything, so I can give you a fresh look
at the process…


>   - Minimise the burden for submitters
>     - Lengthy guidance for submitting patches

Actually, the `16.4 Packaging Guidelines` and `16.6 Submitting Patches`
are everything that I've ever looked for.

The only problem is `16.5.4 Formatting Code` that makes use of 
`./etc/indent-code.el`
that was removed back in January.


>     - Changelog format

"format" and "content".

I've heard about a magic trick in Emacs, but as a user of "the other editor",
I have to write everything manually.

I guess one could write a command that would detect what has changed and
write the changelog. This could also be used on the reviewer/qa side to
check if the patch actually does what it says it does.


>     - Sending patches by email (git send-email)

This one is an easy one!… at least, as long a you only have 1 patch.
For a patch set, one has to generate a cover letter, send it, wait for
a bug id to be assigned then send the rest of the patch set.
Looks trivial, but (too) many times I ended up creating multiple bug
reports for the same patch set. And the fear of messing up the bug report system
was something that discouraged me at the beginning. I still do some
mistake from time to time, but… I do not care any more, because I now
know how to fix them.


>     - Delay in feedback for first time submitters

It doesn't actually have to be a human feedback. But being able to know
that everything went well (or not) and what's the status of a patch is
would be great.


> - Learn how to review more patches

Also learn how to review your first patch! Being able to push a "+1"
button in the QA interface might be useful?
For the time being, I don't know what feedback from me could be useful
for a commiter and how to provide it.


> - Doing useful things with little time

Go through the list of "Update to X.Y.Z." patches, have a quick glance
and push the "+1" button?


> Actions:
>  - teams thing for finding out about patches, automate this somehow
>  - generate a web page listing the people and teams
>  - Filtered subscription to patches by team

What the status on this? Where can I learn more about how teams work?


>  - Maybe script making contributions like updating packages
>  - Make a similar tool to Debian's how can I help
>    - Try to avoid suggesting updating packages with lots of dependencies

`guix how-can-i-help` would be amazing! Something that would:
- list all the packages in my current profile that can be updated,
  sorted by number of dependent packages; and
- list all the packages in my profile that are currently broken.

Actually, for the second point, I guess I'll figure out when upgrading
my profile. Or maybe `guix weather` can help!?

I guess I'll have to dive more into QA, Data Service, Weather to be of
any help. But if you see anything that requires zero-knowledge just let
me know! 😁

Regards,

-- 
Tanguy



reply via email to

[Prev in Thread] Current Thread [Next in Thread]