Guix QA

Table of Contents

-- mode: org --

This service is intended to assist with quality assurance within Guix. That is maintaining and improving the quality of many aspects of Guix, like packages for example.

1. Local Development

Use the guix-dev.scm file to provide the dependencies. 

guix environment -l guix-dev.scm

Then run the following commands: 

./bootstrap.sh
./configure
make

After that, you can start the service via: 

./pre-inst-env scripts/guix-qa-frontpage

Expect pages to load slowly since the QA frontpage won't have up to date cached data to use.

2. Ideas

2.1. For branches

2.1.1. TODO Show broken packages

2.1.2. TODO Show broken system tests

  1. TODO Submit builds for branch system tests

2.1.3. TODO Show broken fixed output package derivations

2.1.4. TODO Show lint warnings

2.1.5. Branch comparisons

  1. TODO Show broken system tests
  2. TODO Show broken fixed output package derivations
  3. TODO Show new lint warnings

2.1.6. TODO Show package reproducibility statistics

This will provide a better URL and faster page load times compared to directly going to data.guix.gnu.org or data.qa.guix.gnu.org.

2.2. For patches

2.2.1. TODO Show and describe the overall status on the page for an issue

2.2.2. TODO Improve display of lint warning changes

  1. TODO Say which package the lint warnings apply to

2.2.3. TODO Show when there are comments/messages on the issue

To highlight when there is discussion that might need reading before merging the patch.

2.2.4. TODO Show changes with system tests

  1. TODO Submit builds for system tests when affected by patches

2.2.5. TODO Extend testing for patches

  1. TODO Cross-compilation from x86_64-linux

    This can be enabled, but data might often be lacking due to lack of build resources for bordeaux.guix.gnu.org

  2. TODO powerpc64le-linux

    The one powerpc64le-linux build machine for bordeaux.guix.gnu.org isn't always on (this could be fixed by changing the hosting). Anyway, some always available build machine for powerpc64le-linux is probably needed before extending patch testing.

  3. TODO i586-gnu

    Builds are now happening on bordeaux.guix.gnu.org, once it's caught up, enabling i586-gnu should be possible. There might be issues with a lack of build resources (like x8664-linux).

2.2.6. TODO Run licensecheck on package sources

And highlight changes or when this doesn't match what's declared in the Guix package.

2.3. QA Ecosystem

2.3.1. data.qa.guix.gnu.org

  1. TODO Move away from Chris renting beid (the machine it runs on)
  2. TODO Make processing revisions faster and require less resources

2.3.2. Monitoring and observability

  1. TODO Move away from Chris hosting Prometheus/Grafana for this purpose

    Either to Prometheus packaged for Guix and run on Guix machines, or some other approach.

2.3.3. Keeping Guix packages up to date

  1. TODO Automated patch submission for package updates

    Using guix refresh. This way the manual work is reduced, and it's easier to just apply the package updates that have been tested.

    1. TODO Speed up QA for patches

      As this would result in more patch series, QA (mostly the data service) will need speeding up a lot to make this feasible.

2.3.4. Facilitating people without commit access reviewing patches

This might help speed up getting patches merged, and get more people involved in the process. Maybe the QA Frontpage has a part to play in helping this to happen.