From: Tanguy LE CARROUR <tanguy@bioneland.org>
To: Christopher Baines <mail@cbaines.net>, guix-devel@gnu.org
Subject: Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event
Date: Wed, 05 Oct 2022 16:01:40 +0200 [thread overview]
Message-ID: <166497850086.2821.11724664487538606446@localhost> (raw)
In-Reply-To: <87a66wfzeh.fsf@cbaines.net>
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
next prev parent reply other threads:[~2022-10-05 14:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-18 15:55 Notes from discussion on Quality Assurance from the 10 Years of Guix event Christopher Baines
2022-10-05 14:01 ` Tanguy LE CARROUR [this message]
2022-10-05 16:51 ` Christopher Baines
2022-10-09 15:58 ` Tanguy LE CARROUR
2022-10-18 16:19 ` Tanguy LE CARROUR
2022-10-19 9:57 ` zimoun
2022-10-23 15:40 ` Tanguy LE CARROUR
2022-10-24 7:34 ` zimoun
2022-10-24 11:43 ` Tanguy LE CARROUR
2022-10-23 21:33 ` kiasoc5
2022-10-19 19:31 ` Efraim Flashner
2022-10-23 15:48 ` Tanguy LE CARROUR
2022-10-24 7:44 ` zimoun
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=166497850086.2821.11724664487538606446@localhost \
--to=tanguy@bioneland.org \
--cc=guix-devel@gnu.org \
--cc=mail@cbaines.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 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).