From: "Dave Johansen" <davejohansen@gmail.com>
To: "Discussion of RPM packaging standards and practices for Fedora" <packaging@lists.fedoraproject.org>
Sent: Monday, July 13, 2015 3:44:43 PM
Subject: Re: [Fedora-packaging] Github URL clarification

On Tue, Jun 23, 2015 at 10:48 PM, Pierre-Yves Chibon <pingou@pingoured.fr> wrote:
On Tue, Jun 23, 2015 at 04:46:15PM -0700, Gerald B. Cox wrote:
>    Michael,
>    My belief is that if someone uses the "Release" mechanism, that is covered
>    by
>    the sentence which states: A
>    "If the upstreamA doesA create tarballs you should use themA as tarballs
>    provide an easier trail for people auditing the packages."
>    By creating the tag, upstream has clearly indicated their intent; A who
>    are we to second-guess them? A

I disagree on this as tags are not something that is definitive.
There is a way in github to upload a given tarball and that is then definitive
but just pushing a tag isn't.
There are really too many upstream moving a tag around.

The whole point of the guidelines is to address this specific problem: tags in
github are not definitive, which means they cannot be approach like a version on
pypi or cpan or other platform.


>    The commit hash part comes into play when a Revision or Tag has not been
>    created.

Well, if there is not release, there is no other way than using the hash, but
tags are not releases and thus should not be consider as such.

I agree that tags have potential problems, but it seems that a lot of projects are not doing releases and are only using tags. I think that coming up with a standard policy of how to handle that would be a really good thing. I'm not familiar with all of the download options from github, but if there's a way to make the hash of the commit be part of the URL, then that should help address the issue with tags changing.

Maybe that's because the guidelines still uses old GitHub API instead of the latest version [1]. Or at least I have a hard time to find the documentation for /owner/repo/archive .

[1] https://developer.github.com/v3/repos/contents/#get-archive-link
--
Radek HolĂ˝
Associate Software Engineer
Software Management Team
Red Hat Czech