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

[Christopher Baines]

Tanguy LE CARROUR <tanguy@bioneland.org> writes:

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

I think the point here is that the Submitting Patches section is quite
long.

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

The latest version of the manual suggests using guix style, so this is
maybe a problem limited to old versions of the manual?

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

I think there's room for improvement here in terms of telling people not
to worry about it too much, plus providing more guidance on the format
and common examples.

There's also tooling like the etc/committer.scm script which I don't
know anything about really, but it seems to handle writing this message
in some cases.

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

Indeed, this is still an issue.

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

Yep, and I think we are getting close to being able to do that.

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

Yep, I think Arun had some useful ideas on this back in February
[1]. Particuarly including a checklist somewhere (issues.guix.gnu.org or
maybe qa.guix.gnu.org).

1: https://guix.gnu.org/en/blog/2022/online-guix-days-2022-announcement-2/

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

There's been a few messages to guix-devel. It's not something I know
much about either.

From my perspective, I'd like to be able to use this information in the
qa-frontpage. I think the path to make that happen involves moving the
work currently done through Laminar to create the branches for patch
series in to the qa-frontpage, as that should make it easy to access the
files changed in a patch series.

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

Indeed :)

> 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! 😁

Please let me know if I can help with any of this. The QA frontpage in
particular should have a bunch of easier things to do, and I've got a
rough list of tasks I put together here [2].

2: https://git.cbaines.net/guix/qa-frontpage/about/

Thanks,

Chris

signature.asc
Description: PGP signature