Re: "Entry: NA" in debian/upstream/metadata

[Steffen Möller <steffen_moeller@gmx.de>]

Am 04.03.21 um 17:12 schrieb Andrius Merkys:
> Hi Charles,
>
> On 2021-03-04 07:06, Charles Plessy wrote:
>> how about YAML's null value for entries for which it was confirmed that
>> the information does not exist ?
> This was my initial idea. I do not know much about YAML, but at least
> Perl YAML implementations see no difference between different ways of
> specifying undefined/null in YAML. I tried both YAML and YAML::XS
> modules, and both seemingly do the same:
>
> perl -MYAML -MData::Dumper -we 'print Dumper Load($ARGV[0])' 'field: ~'
> $VAR1 = {
>           'field' => undef
>         };
>
> perl -MYAML -MData::Dumper -we 'print Dumper Load($ARGV[0])' 'field:'
> $VAR1 = {
>           'field' => undef
>         };
>
> perl -MYAML -MData::Dumper -we 'print Dumper Load($ARGV[0])' 'field: !!null'
> $VAR1 = {
>           'field' => undef
>         };
>
> Maybe I am doing something wrong, but currently I am under impression
> that YAML does not have enough flavors of "unknown" to cater our needs.

This reminds me of the early days of my computer science education with
the question if {} and {{}} are the same thing. They are not. My first
idea was that the parser is to blame, but the example at
https://yaml.org/type/null.html makes the same
what-I-consider-to-be-a-mistake. I am a fan to use the ~ as a proper NA
substitute but there is little point if we cannot distinguish it from
nothing when parsing it.

Somewhere else was the suggestion made to also add a time stamp. This
makes perfect sense for the NA/~ and in that case, if that date was
specified, we know that unknown is a confirmed unknown. For entries that
are found, we should possibly just rely on git blame in salsa.

Thank you all!

Steffen