[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Notes from discussion on Quality Assurance from the 10 Years of Guix eve
From: |
Christopher Baines |
Subject: |
Notes from discussion on Quality Assurance from the 10 Years of Guix event |
Date: |
Sun, 18 Sep 2022 17:55:30 +0200 |
User-agent: |
mu4e 1.8.9; emacs 28.1 |
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
signature.asc
Description: PGP signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Notes from discussion on Quality Assurance from the 10 Years of Guix event,
Christopher Baines <=