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

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

Here are some notes I took during the discussion on patch review/quality
assurance at the 10 Years of Guix event.

Discussion:
- Find out how others review patches
  - Julian
    - Subscribe to guix-patches
    - Look at subjects
    - If not OCaml/Java/Maven, ignore email
    - If obvious issues can be seen, reply suggesting improvements
    - Run guix lint/build dependents
    - There are language/area specific things that are good to know
      about when reviewing patches

- How the process works
  - How we can improve quality of Guix, avoid breakages
  - How we can simplify the workflow for reviewers
  - Minimise the burden for submitters
    - Lengthy guidance for submitting patches
    - Changelog format
    - Sending patches by email (git send-email)
    - guix lint archive error
    - Delay in feedback for first time submitters

  - Problems
    - Already broken packages when applying updates

- How to help?

- Motivation to do more
  - Debian: How can I help tool?
- Learn how to review more patches
- Doing useful things with little time


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

 - Improve the qa.guix.gnu.org site
 - look at moving Mumi, QA Frontpage, ... on to Savannah
 - List infrastructure projects on a web page

 - More detailed guidance on the review process
 - Guidance for reviewers, e.g. don't ask for patch submitters to fix
   other problems
 - Split the guidance for submitting patches in to sections (bronze,
   silver, gold)
 - Give specific guidance for different tasks, so don't run lint if
   you're upgrading a package
 - Have some "trusted reviewer" status
 - Arrange focused time per month/week when people try to review patches
 - How should reviewers get patches merged when they don't have commit
   access?
 - 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

 - work out what is getting in the way of patches getting to the mailing
   list/debbugs
   - Put a warning about delays

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]