[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