Add basic ADR doc setup and first LVM ADR
This commit introduces Architectural Decision Records. To quote: > Architectural Decision Records (ADRs) > > An Architectural Decision (AD) is a software design choice that > addresses a functional or non-functional requirement that is > architecturally significant. An Architecturally Significant > Requirement (ASR) is a requirement that has a measurable effect on a > software system’s architecture and quality. An Architectural Decision > Record (ADR) captures a single AD, such as often done when writing > personal notes or meeting minutes; the collection of ADRs created > and maintained in a project constitute its decision log. All these > are within the topic of Architectural Knowledge Management (AKM), but > ADR usage can be extended to design and other decisions (“any > decision record”). Taken from https://adr.github.io/ This commit also adds the first ADR; both as an example as well as a serious proposal. This ADR is a product of discussions around encrypted swap, hibernation, onboarding of new devices, and fragmentation.
This commit is contained in:
parent
e26ffd2725
commit
6fca77a69f
13
doc/adr/01-lvm.md
Normal file
13
doc/adr/01-lvm.md
Normal file
|
@ -0,0 +1,13 @@
|
|||
# PubSolarOS ADR 01: LVM on luks as default for drive management
|
||||
|
||||
In the context of drive mounting and disk partitioning,
|
||||
|
||||
facing a fragmented ecosystem,
|
||||
|
||||
we decided for LVM on luks with encrypted swap as the assumed default installation type,
|
||||
|
||||
and neglected luks on LVM, unencrypted installs, or non-LVM install methods,
|
||||
|
||||
to achieve a streamlined and opiniated nix config, an increased flexibility in partitioning, and more secure defaults,.
|
||||
|
||||
accepting a more laborious setup.
|
3
doc/adr/README.md
Normal file
3
doc/adr/README.md
Normal file
|
@ -0,0 +1,3 @@
|
|||
# Architectural Decision Records
|
||||
|
||||
**For an explanation of ADR, see https://adr.github.io/**
|
27
doc/adr/TEMPLATE.md
Normal file
27
doc/adr/TEMPLATE.md
Normal file
|
@ -0,0 +1,27 @@
|
|||
# Long form
|
||||
|
||||
In the context of <use case/user story u>,
|
||||
|
||||
facing <concern c>
|
||||
|
||||
we decided for <option o>
|
||||
|
||||
and neglected <other options>,
|
||||
|
||||
to achieve <system qualities/desired consequences>,
|
||||
|
||||
accepting <downside d/undesired consequences>,
|
||||
|
||||
because <additional rationale>.
|
||||
|
||||
# Short form
|
||||
|
||||
In the context of <use case/user story u>,
|
||||
|
||||
facing <concern c>
|
||||
|
||||
we decided for <option o>
|
||||
|
||||
to achieve <quality q>,
|
||||
|
||||
accepting <downside d>.
|
Loading…
Reference in a new issue