Even though, this ADR documents something already implied in the TUF
spec in [document formats](https://theupdateframework.github.io/specification/latest/#document-formats)
it seems better to document this decision clearly so that it could be
referenced and give an explanation why someone can load a metadata file
with additional unrecognized fields.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Use Google style guide with refinements, because the Google style
guide is a comprehensive, well-established style guide that is
mostly based on PEP-8 and was accepted by everyone on the TUF team.
There is no need to replicate these recommendations. However, we do
provide a very slim document with additional refinements, in order
to emphasize on items the we consider especially important, want to
be handled differently, or in one specific way, where the Google
guide would allow multiple.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Co-authored-by: Joshua Lock <jlock@vmware.com>
Add MADR that justifies why we want to add custom classes for
complex tuf metadata attributes.
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Describe pros of developing TUF 1.0.0 in a subdirectory
of the current implementation against the rest of the options.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
Document the outcome of #1126 to develop TUF 1.0.0
in a subdirectory of the current TUF implementation.
Signed-off-by: Teodora Sechkova <tsechkova@vmware.com>
Provide additional context to clarify where we expect Python 3.6+ to be used
exclusively (new modules) and link to other discussions around the future of
Python 2.7 supporting code.
Signed-off-by: Joshua Lock <jlock@vmware.com>
In order to make decisions about the code and the design explicit and easier
to reference in future we want to record significant architectural decisions.
This commit introduces docs/adr with a template Architectural Decision Record
and index using the [MADR](https://adr.github.io/madr/) format.
It also adds ADR 0000 to document the decisions to use MADR.
Fixes#1141
Signed-off-by: Joshua Lock <jlock@vmware.com>
