Hi Charles, Andreas,

DEP-12 appears to have been stalled for a while in the draft phase; I'd be keen to see if it can be moved forward - and would really appreciate any suggestions on how to help do so.

Adoption
========

It looks like there are already close to 5000 debian/upstream/metadata files in the archive at this point. There are specific fields that appear much more frequently than others:

key | count
-------------------+-------
Repository | 5483
Bug-Database | 5164
Repository-Browse | 5035
Bug-Submit | 3989
Archive | 3253
Name | 1830
Contact | 1554
Changelog | 439
Documentation | 65
ASCL-Id | 65
FAQ | 49
Registration | 47
Screenshots | 40
Cite-As | 38
Other-References | 36
Donation | 26
Webservice | 16
Gallery | 16
Security-Contact | 15
Funding | 8
CPE | 5

(this data comes from UDD from a month or two ago so it excludes more complex fields like the Reference field, of which there are close to 1000 instances according to codesearch.debian.net).

Use Cases
=========

One of the things that I was curious about is the intended audience for https://wiki.debian.org/UpstreamMetadata, as well as the relationship to
other control files. I know why I am personally interested in some of these fields
- e.g. using the Bug-Database to build tools to cross-check the Debian BTS and the upstream BTS for bugs that exist in both or Repository to e.g. cross-check whether patches have made it in upstream.

The three kinds of control files that I can think of are:

* debian/control
* DEP-11 (appstream)
* DEP-12 (upstream-metadata)

(are there any other relevant files? what about DOAP?)

My guess is that their distinction and use case is something like this:

* debian/control: Debian-specific /package/ metadata, intended for developers (and their tools) and power users (i.e. not people using gnome-software)
* DEP-11: /application/ metadata for end-users (i.e. people using gnome-software)
* DEP-12: non-Debian-specific /package/ metadata

Is that a reasonable interpretation?

There are some existing fields that don't really follow match those categorizations:

* the field with the upstream metadata "Homepage" lives in
debian/control and rather than DEP-12.
* as discussed previously, Contact and Name live in debian/copyright rather
than debian/upstream/metadata

Next Steps
==========

Would it make sense to standardize the current proposal as DEP-12, perhaps with a limited set of uncontroversial and widely used fields?

Cheers,

Jelmer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Aug 14, 2020 at 4:37 PM Jelmer Vernooij wrote:

Would it make sense to standardize the current proposal as DEP-12, perhaps with
a limited set of uncontroversial and widely used fields?

I wonder if storing metadata (including Homepage, debian/watch, debian/upstream/*) about the upstream project in the Debian source
package is the wrong approach. Upstream metadata can change without
any need for the Debian source package to change (like them switching
hosting platforms or bug reporting software).

--
bye,
pabs

https://wiki.debian.org/PaulWise

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Aug 14, 2020 at 4:37 PM Jelmer Vernooij wrote:

Would it make sense to standardize the current proposal as DEP-12, perhaps with
a limited set of uncontroversial and widely used fields?

Le Sat, Aug 15, 2020 at 01:04:35AM +0000, Paul Wise a écrit :

I wonder if storing metadata (including Homepage, debian/watch, debian/upstream/*) about the upstream project in the Debian source
package is the wrong approach. Upstream metadata can change without
any need for the Debian source package to change (like them switching
hosting platforms or bug reporting software).

Hi Paul and everybody,

indeed my vision when I started the debian/upstream project was to keep
the data up to date in the VCS that holds the Debian source package,
without tying updates to source uploads, and let data gatherers collect
the information periodically.

I am not going to discuss the pros and cons of centralised versus
decentralised in this thread, but my idea was that, following a
decentralised approach, the source package VCS was a good place to store
and redistribute the information, because the whole infrastructure is
already there for free.

Have a nice day,

Charles

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Aug 15, 2020 at 01:04:35AM +0000, Paul Wise wrote:

I wonder if storing metadata (including Homepage, debian/watch, debian/upstream/*) about the upstream project in the Debian source
package is the wrong approach. Upstream metadata can change without
any need for the Debian source package to change (like them switching
hosting platforms or bug reporting software).

As usual, I'll have to remind people that this is the usual old topic.


Just keep in mind that:
* we used to have a centralized d/watch overrides in the form of MOLE,
but that eventually bitrot and was removed
* as Charles Plessy mentioned, there used to be a centralized VCS for
DEP-12 stuff, but that was also pretty much abandoned IIRC
* people keep talking about moving VCS-*, Maintainer, Uploaders, etc
etc out of d/control, and has been doing so for many years. The only
related thing I'm aware of is the possibility of adding an override
in vcswatch (which is not possible anymore now after quantz's update
to buster, incidentally), which is a relatively new project. Nobody
came forward and did any of the work needed to take Maintainer out of
d/control.


So, IMHO, any further discussion about "is it sensible to keep $this in
debian source package" is totally pointless until somebody actually
comes up with a working, maintained, etc solution.

--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl85I8YACgkQCBa54Yx2 K60apA/9Hs+MtWEKSd8RE1HI3YZhdVr26u0x2gtPwFeRjXp8MJjAa372m2Hb/B9b 7pdr4ycwvOhgoDr7YsAkQofdV+N7TV2l3EEIBFbHcctyEgkPdXliZftopBVBQFg9 0DPfRkNSV+Kkg3vJGcLp0u1JTFvSzuP2BWArQ/OpwjHhPxZX7/uotMOUa1CgBHl3 WU+UB6OOb986U+gND4OktrhR228wY8DkV0kzz3RrUFQzbwbX7GqlnLwpbDbplW97 dW6V/ULvC8QJMUgBu5XcEUpzsWM48E1V3SbWeor5pO/MXqBiMaogaXooK8ss3o5u V89lrLgWJohK2WxwevbZI0ktc75Kqg9SzCkamd6jYNKrzafJbsyiIC0QFukfJ+qL j+BtuOJ4jSg7Kzpn6rnLXoFSqKrbVmUnvu9vWMseR+XHOSC6g8I3QOX6dB5j1Wr4 ETgcY3GIjdyEGSx9BXzxdq7Kqezn6gyog2ByJyEKtp/TULT70YOsSp7Rh7cy6EM/ VIAESBr7JOvYU1lXb60NQlPXlBbw9bnHYisAvYUBEUdvgoHw4zk

On Sun, Aug 16, 2020 at 02:17:13PM +0200, Mattia Rizzolo wrote:

On Sat, Aug 15, 2020 at 01:04:35AM +0000, Paul Wise wrote:

I wonder if storing metadata (including Homepage, debian/watch, debian/upstream/*) about the upstream project in the Debian source
package is the wrong approach. Upstream metadata can change without
any need for the Debian source package to change (like them switching hosting platforms or bug reporting software).

As usual, I'll have to remind people that this is the usual old topic.

Just keep in mind that:
* we used to have a centralized d/watch overrides in the form of MOLE,
but that eventually bitrot and was removed
* as Charles Plessy mentioned, there used to be a centralized VCS for
DEP-12 stuff, but that was also pretty much abandoned IIRC
* people keep talking about moving VCS-*, Maintainer, Uploaders, etc
etc out of d/control, and has been doing so for many years. The only
related thing I'm aware of is the possibility of adding an override
in vcswatch (which is not possible anymore now after quantz's update
to buster, incidentally), which is a relatively new project. Nobody
came forward and did any of the work needed to take Maintainer out of
d/control.

So, IMHO, any further discussion about "is it sensible to keep $this in debian source package" is totally pointless until somebody actually
comes up with a working, maintained, etc solution.

Source packages indeed don't seem like the ideal place for this data,
but because of the points raised by Mattia I wonder if that should be
a separate discussion.

There is a lot of adoption for the current DEP-12 draft in source
packages. It would be useful to at least bless the de-facto
standard and encourage its use (both by tools reading the data and
packagers provide the data). There is value in having this be an
official standard and standardising the fields and their syntax,
regardless of whether we'd want to eventually move this data
elsewhere.

Jelmer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)