Your message dated Sat, 09 Sep 2023 21:12:48 -0700
with message-id <87wmwyzmwv.fsf...@hope.eyrie.org>
and subject line Re: Bug#904608: Include upstream metadata spec in Policy
has caused the Debian Bug report #904608,
regarding Include upstream metadata spec in Policy
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
904608: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904608
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-policy
Version: 4.1.5.0
Severity: normal
Hi,
Some tools, like git-buildpackage, can support merging an upstream's
version history into Debian packaging repositories. This enables more
rich usage of (D)VCS when packaging - for example `git blame' works
properly.
Currently there's no canonical place to specify where upstream's VCS is
located so people have to set this up manually themselves. If there were
such a place, it would be possible for tools like `gbp clone' to
configure the VCS to know about the upstream history when checking out a
packaging repository.
The request here is to ask whether this would be suitable for
debian/control, along the lines of the Vcs-* fields specified in 5.6.26
and the Homepage field in 5.6.23.
If so, I'd be happy to propose wording for policy. I'm not set on any
particular name, so please feel free to weigh in on that if you'd like.
Cheers,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
--- End Message ---
--- Begin Message ---
Sean Whitton <spwhit...@spwhitton.name> writes:
> On Thu 26 Jul 2018 at 09:21AM +0100, Iain Lane wrote:
>> However, I'm not very keen on the extra work that would be required to
>> transfer that wiki page into policy as opposed to specifying an extra
>> field.
>>
>> Do you agree that policy should recommend such a location and is the
>> path to this recommendation, in your opinion, a ratification of the
>> UpstreamMetadata page or something like it?
> No-one needs to do that extra work anytime soon. Policy lags best
> practices. The fact that debian/upstream/metadata is already being used
> to store a URI to the upstream repository for a large number of packages
> counts as standardisation, in Debian Policy terms. You can refer to it
> in tools that you write.
> We should eventually move the upstream metadata spec into Policy. I'm
> retitling the bug, but also tagging it as moreinfo. The moreinfo tag is
> used to indicate that it is not clear that the bug against debian-policy
> is actionable.
> What is currently unclear is whether the upstream metadata spec is
> sufficiently mature to go into Policy. We need to hear from those
> involved with that spec that it's sufficiently mature to go into Policy.
> If it's sufficiently mature, such that all that's needed is writing a
> patch to Policy, we can remove the moreinfo tag and leave the bug open,
> awaiting someone driving its inclusion in Policy. If the spec is not
> ready to go into Policy, then there is no Policy work to be done, and we
> should close the bug.
It's now five years later and there hasn't been any forward progress on
including the upstream metadata spec into Policy or confirming whether it
is stable. There has also been some disagreement with this idea from
Guillem, who would like the data in a format that dpkg can read rather
than YAML (which I assume he is unwilling to add as a dpkg dependency),
and from Ian, who doesn't like the YAML format.
I'm therefore going to conclude that we don't have support or energy for
making a Policy change at this time and am going to close this bug.
Someone who feels that the upstream metadata spec should be adopted by
Policy and wants to push that forward is free to open a new bug to pursue
that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
--- End Message ---
