/* QA checks/verification */ necessity for verification

1 files changed, 9 insertions, 0 deletions

diff --git a/GLEP:73.mw b/GLEP:73.mw
index 86e1884..1ebebc0 100644
--- a/GLEP:73.mw
+++ b/GLEP:73.mw
@@ -237,6 +237,15 @@ For most of the real-life use cases, two iterations should be able to solve all
  c? ( d ) b? ( c ) a? ( b )
 
 ===QA checks/verification===
+====The necessity of verification====
+The purpose of REQUIRED_USE constraint verification is to ensure that for all valid combinations of input USE flags, the solver will be able to find a valid solution. This needs to be done explicitly since complex REQUIRED_USE constraints may trigger solving issues with non-obvious USE flag combinations, causing the developers to miss the issue.
+
+Since the solver must be able to deal with non-solvable constraints (by reporting them and letting the user deal with them), verification is not a strict necessity for enforcing REQUIRED_USE. However, it improves the user experience, and so is a worthwhile addition to the QA tools in place.
+
+To provide the best coverage, it is beneficial to integrate the verification into the tools commonly used by developers — repoman and pkgcheck, including the CI runs. For this to be possible, the algorithm must meet two requirements:
+* it must be fast enough not to cause significant increase in repoman/pkgcheck run time for the full repository,
+* it must not trigger a large number of false positives, and if any are triggered, they should be easy to work around.
+
 ====Context to the checks====
 As noted in the specification part, all of them checks need to be repeated for all possible sets of the immutable flags. This is necessary since the immutable flags can alter the solutions significantly. In particular:
 * they can alter the preferred choices in the any-of, at-most-one-of and exactly-one-of groups,