1) the update didn't happen for all but the first
2) we don't want a package that fixes a regression in unstable to influence the
reference for another package until it actually migrates, so this updating
is flawed.
All the output is a duplicate of what is being sent to the root logger
(albeit in a different format) and in e.g. our test suite the output
is entirely redundant.
Signed-off-by: Niels Thykier <niels@thykier.net>
With a bit of code we can replace the manual file-handling for
"upgrade_output" with a logger. This will enable us to refactor other
bits that currently depend on "output_write" by making those bits use
a logger instead.
This also migrates "do_hint" to use the new output logger. This is
due to "do_hint" being the only method relying on writing of partial
lines and maintaining support for that in "output_write" would have
been non-trivial.
To ensure "pretty" formatting to stdout, the messages in
"output_write" are now chopped into multiple lines.
The only visible change is that the output to stdout from
"output_write" now also includes the prefix with a timestamp.
However, then contents of "upgrade_output" remain unchanged
deliberately.
Signed-off-by: Niels Thykier <niels@thykier.net>
We already know the item is successful when we print it and the next
line ("final:") will confirm it any way.
Signed-off-by: Niels Thykier <niels@thykier.net>
AFAICT all of the items are no longer relevant. Not to mention we
have a separate bug tracker (now?) that is much more suited for bugs
plus sphinx docs that could easily grow a "Known Issues" section as
well.
Signed-off-by: Niels Thykier <niels@thykier.net>
Given that only one value is defined ("reference"), it is a better
option to allow the config to be unset when one does not want to have
adt_baseline set to "reference".
Signed-off-by: Niels Thykier <niels@thykier.net>
Notable omissions are "pending_tests" and "tests_results". This is
omission is due to these (some times) being initialized from the
output of "json.load" (so we cannot assume defaultdict semantics
without manually imported the data into one).
Signed-off-by: Niels Thykier <niels@thykier.net>
The first case is to avoid a creating a list, which is then converted
to a set only to throw away the list again. Here we can just create
the set right away without a list inbetween.
The second case is "if x in [...]:" is better written as "if x in
{...}:" as sets provides faster "__contains__" (assuming you are on a
"recent enough python3", which britney is).
Signed-off-by: Niels Thykier <niels@thykier.net>
Niels Thykier
Paul Gevers