docs(architecture): record key design decisions as ADRs #22
No reviewers
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Discussion
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Help Wanted
Status
Need More Info
Prio - Hoog
Prio - Laag
Prio - Middel
styling
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
MinBZK/DAWO-NixOS!22
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "bram.buijs/DAWO-NixOS:feat/adr-architecture"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
References #1.
Adds an Architecture Decision Records section to
architecture.md, capturing thedecisions behind this series so the reasoning lives next to the code. Short
records, newest on top, each with context / decision / consequence:
(#8).
Question: ADRs inline in
architecture.mdas here, or a separatedocs/adr/tree? And does #1 cover this, or should it hang off a small docs issue instead?
@ -21,0 +109,4 @@- Context: lanzaboote v1.0.0 sets `boot.bootspec.enable`, which nixpkgs 26.05removed, so the pinned tag fails to evaluate on the current nixpkgs.- Decision: track lanzaboote from master until a tagged release is compatible.- Consequence: Secure Boot hosts evaluate again; revisit when a new tag lands.Let's create an open issue to track this periodically.
LGTM 👌please open the requested tracking issue and I'll merge.
95932430edtoda482eef1fOpened the tracking issue: #28. It captures the ADR home/upkeep and the inline-vs-
docs/adr/question, split off from #1 as you asked. Good to merge whenever you are.