Re: "Entry: NA" in debian/upstream/metadata
Hi Andrius,
On Wed, Mar 03, 2021 at 09:54:21AM +0200, Andrius Merkys wrote:
> > The latter might be useful for contributors who aren't used to all those
> > IDs, to make them more visible (including where the gaps are). But on
> > the other hand, if those are well present in an upstream/metadata
> > template and very clear in the documentation of upstream/metadata, then
> > it is not necessary and I'd then tend to like your suggestion Andrius.
>
> To me, three flavors of "unknown" looks like an overkill. Most of the
> metadata in Debian does not even have the two flavors of "unknown":
> missing Bug-Submit field in d/u/metadata, Homepage in d/control and
> Upstream-Contact in d/copyright means that this piece of information is
> either nonexistent or simply not entered (for example, due to the lack
> of time). Thus I am not sure whether the added value is worth the
> infrastructure/effort here. But again, this is solely my opinion,
> certainly not aimed at reflecting those of the people who enter and use
> the data in d/u/metadata.
I wrote the UDD importer for the metadata files and thus look at the
data as a "consumer" of the provided information. From this side those
different meanings of unknown are all turned into "ignore this value".
So in this respect differentiating between those unknowns is basically
helpful for those who edit the metadata files. Flagging something as "I
was here and have checked" is probably kind of helpful. However, it
might perfectly be that some registry will include that specific
software later and re-checking makes sense.
For this reason I was recommending to not make those simple things to
complex since making it complex just drains time from the people who are
working on it with no visible effect to the users.
> If three flavors option would be preferred, I would also suggest adding
> date fields for each entry to signal at which point in time the registry
> was inspected.
As I wrote above later addition of some software to some registry can
spoil the different meanings of unknown. This could be cured by such a
date field but I don't think it is of any better value than draining
time from people maintaining that extra field. Thus I do not think we
should do this.
Thanks a lot for your work on this
Andreas.
--
http://fam-tille.de
Reply to: