Status: Accepted (2026-10-06).

Parsing Qt repository metadata — directory listings and Updates.xml — is the part of qtogo that upstream breaks most often, so it needs tests that run offline and that we control. Two sources are possible: data we write ourselves, and the corpus the reference implementation accumulated.

The repository layout is an external protocol we do not own, but our model of it is ours to define. Real upstream data contains shapes that are easy to miss when writing fixtures by hand: namespaces, package naming conventions, empty fields, unusual ordering, extra metadata.

1. Project-owned fixtures are the primary corpus, organised around the repository model we support rather than around another project's tests:

   testdata/
   ├── repository/
   │   ├── qt5-flat/          index.html + Updates.xml
   │   ├── qt6-nested/        index.html + Updates.xml
   │   ├── qt6-arch-split/    Updates.xml
   │   ├── malformed/         broken.xml + invalid.html
   │   └── not-found/         404.html
   └── upstream/
       └── aqt/               selected third-party cases, attribution required
   

   They carry only the fields the parser needs, so a fixture states one behaviour rather than reproducing a release:

   <Updates>
     <PackageUpdate>
       <Name>qt.qt6.680.win64_msvc2022_64</Name>
     </PackageUpdate>
   </Updates>

2. A small upstream corpus may be added as interoperability regression cases only, under testdata/upstream/, with attribution and a pinned source version. Core discovery and parse tests must not depend on it: its job is to catch regressions on real-world shapes, not to define our contract.

3. The corpus is predominantly project-owned, with roughly 90/10 as a maintenance guideline rather than a test requirement: the mix is not something to tune a suite towards, so a drift to 94/6 or 85/15 is not a problem to fix.

4. Fixtures never contain real URLs. A fixture identifies a layout, or is served from a fake repository root, so a test is offline by construction and cannot accidentally reach a real server.

5. This is the wording for the documentation:

   Offline fixtures are primarily project-owned minimal fixtures designed around qtogo's supported repository model. Selected fixtures from compatible open-source projects may be included only as interoperability regression cases with attribution.

• The upstream corpus brings an attribution obligation and needs a recorded source and version, plus a policy for refreshing it.
• Our own fixtures have to be extended whenever a new real-world shape is learned; that gap is exactly what the upstream corpus covers in the meantime.
• A parser test that needs a fixture not in testdata/repository/ is a signal that our model gained a case, not that we should import more upstream data.

• Project-owned fixtures only. Rejected: it loses the real-world shapes that are tedious to invent, and those are the ones that break parsers.
• Copy the reference implementation's corpus wholesale. Rejected: it binds our tests to another project's semantics, a large part of that corpus tests behaviour we do not have (legacy paths, internal details), and the maintenance and attribution cost would exceed the value.