diff options
Diffstat (limited to 'README.org')
| -rw-r--r-- | README.org | 111 |
1 files changed, 6 insertions, 105 deletions
@@ -1,5 +1,7 @@ -*- mode: org -*- +Available online at https://qa.guix.gnu.org/README + 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. @@ -34,111 +36,10 @@ cached data to use. #+CAPTION: Diagram describing how information moves between different components [[./qa-information-flow.png]] -* Ideas -** For branches -*** TODO Show broken packages -*** TODO Show broken system tests -**** TODO Submit builds for branch system tests -*** TODO Show broken fixed output package derivations -*** TODO Show lint warnings -*** Branch comparisons -**** TODO Show broken system tests -**** TODO Show broken fixed output package derivations -**** TODO Show new lint warnings -*** DONE 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. - -** For patches -*** TODO Better handle an influx of new bugs - -Currently when this happens, I think QA may delete a bunch of branches that -now fall outside the latest issues it looks at, only to re-process these once -they reappear as the new issues are dealt with (either by being merged or -closed). - -*** TODO Show and describe the overall status on the page for an issue -*** TODO Improve display of lint warning changes -**** TODO Say which package the lint warnings apply to -*** TODO Show when there are comments/messages on the issue - -To highlight when there is discussion that might need reading before -merging the patch. - -*** TODO Show changes with system tests -**** TODO Submit builds for system tests when affected by patches -*** TODO Extend testing for patches -**** 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 - -**** 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. - -**** 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 x86_64-linux). - -**** TODO Test reproducibility - -This depends on getting more data on builds back to the data service. - -Submit multiple builds for the same derivation. - -*** DONE Improve patches page -**** DONE Add more statuses -**** DONE Support filtering by status -*** TODO Run licensecheck on package sources - -And highlight changes or when this doesn't match what's declared in the Guix -package. - -** QA Ecosystem -*** data.qa.guix.gnu.org -**** DONE Move away from Chris renting beid (the machine it runs on) -**** TODO Support accepting build reports/buildinfo - -This can include the hashes of the output and be factored in to the assessment -of reproducibility. This will allow using the results of multiple builds per -build server, rather than just being able to look at a single substitute. - -*** Monitoring and observability -**** 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. - -*** Keeping Guix packages up to date -**** 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. - -***** 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. -*** 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. +* Bugs and issues -**** DONE Add mark patches as "reviewed-looks-good" feature -** Reproducible builds -*** TODO Improve issue display, show severity and separate by status -*** TODO Record and expose percentage of packages that build reproducibly +Please submit issues here https://codeberg.org/guix/qa-frontpage/issues/new -Compute the percentage, ignoring packages where the status is unknown. Also -ignore systems with little data available. +* Roadmap -Expose in Prometheus metrics, and record in the database. This could be -backfilled by looking through the older data service data. +Available online at https://codeberg.org/guix/qa-frontpage/projects/18699 |