Which of these should block releases?
- Convert detailed client workflow to use sub-procedures
- Goal: less repetition
- Goal: easy to implement and map to the spec requirements (checklist like)
- Update specification tooling to do date and version bumping in GHA
- Implementations should catch up with spec-1.x.y
- Resolution: implementations should explicitly list what they support
- Should implementations refactor their code before implementing new TAPs?
- Resolution: up to implementations to define what they want to do
- TAP 4: Multiple repository consensus on trusted targets (likely to be much easier if the client-workflow -> sub-procedures change is done first)
- TAP 15: Succinct hashed bin delegations (needs implementation & approval)
- TAP 13: User Selection of the Top-Level Target Files Through Mapping Metadata (needs accepting as draft, implementation & approval)
- TAP 16: Snapshot Merkle trees (needs implementation & approval)
- TAP 3: Multi-role delegations (also likely to be easier if client-workflow refactor done first)
- TAP 8: Key rotation and explicit self-revocation (needs implementation & approval)
- TAP 14: Managing TUF versions (needs implementation & approval)
- TAP X: DSSE (needs accepting as draft, implementation and approval)
- Specification refactor by June
- TAP 15 Accepted & in reference implementation by June
- TAP 15 in the spec by end of year
- TAP 3 & 4, work on implementations
- Implement TAP 13 in go-tuf
- All implementations should catch up to 1.x.y by $MONTH and $DATE?