Update the README

1 files changed, 6 insertions, 105 deletions

diff --git a/README.org b/README.org
index 22bce8f..9fd1e00 100644
--- a/README.org
+++ b/README.org
@@ -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