all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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


  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

* 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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.