On Fri, Jun 26, 2015 at 13:49:10 -0400,
Rich Mattes <richmattes(a)gmail.com> wrote:
The biggest complaint I have with this draft is that it introduces a
lot of extra unnecessary work for packagers. Anyone packaging
software coming from a git repository first has to figure out if
they're able to use tags or not, based on a very opaque criteria. How
do you know that a project is moving tags? Can you audit it before
you package it? How much work does that take? Further, once you do
package something, how do you make sure that the tag you used in your
source URL doesn't change? Do you need to check your source checksum
vs upstream when making point releases? Or do you check it monthly or
weekly? Is there any way to automate this process for people that
maintain a lot of packages?
Someone used to run something that would check that the files in packages'
source urls were still fetchable and hadn't changed. I haven't seen a report
from this process in a long time, so it might not be run any more.
As long as github is returning the same bits when it regenerates an archive
file for the same tag (when the tag doesn't change) I think using tags
in URLs is good enough. (Because in theory we can automate checking for
changes without getting lots of false positives.) This appears to be how
things work now.