On Wed, Jun 24, 2015 at 12:32 AM, Pierre-Yves Chibon <pingou@pingoured.fr> wrote:
That is a valid point, but we can reverse the problem:
We can't do anything about upstreams that re-generate multiple times the archive
for the same release, but with the current guidelines we can do something about
the upstreams that are moving tags around.

That sounds to me like a good reason to do so.
...

The only counter-argument I can think of right now is the frequency at which the
abuse occurs on github.
In my experience, it is much more frequent.

Thanks again for taking the time to reply!  

That is a good point, and I agree.  We should always strive to fix things if we can.
My concern is the practical effect of implementing a guideline that says you must 
always use commit hash when packaging source from Git repositories; but if the Project
takes that same archive and uploads it to some URL, that it is now somehow magically golden.
That just strikes me as a bit capricious.

I was a bit surprised at first with the frequency you believe this is happening with Git; 
but I can believe there are many people playing around, experimenting and learning
about Git; and these people can make mistakes mainly because they haven't RTFM; but
I don't think we should be concerned about those particular repositories.  

The ones we are concerned about are the ones that we would want to package; and I really
find it hard to imagine that someone would advance so far in developing something
we would want to package, yet has a remained completely ignorant on how to properly
use their VCS.  

Sorry about the epistle ;-) but to sum up:

Yes, I agree with your point we should fix things if we can; but I don't believe mandating
commit hash in all circumstances is the way to do it.  

Perhaps the better approach (and I plan modify my draft to include this) would be to add a short explanation
cautioning the packager to be aware that there is a chance of abuse when it comes
to Git Tags.  If the packager believes there is abuse, they MUST request upstream to 
resolve the situation.  If upstream refuses, they can either drop their effort to package the
application OR use the commit hash method.

If they use the commit hash method, they MUST put a comment in the Spec file documenting
the fact that upstream is in violation of Git practices and commit hash was used to 
circumvent the situation.  This identifies the bad apples.

Perhaps it's just easier to put a blanket ban on using Git Tags, but I think that approach is 
a bit ham-handed.  This is a bit more nuanced, addresses the concern and goes
after the root cause, which is an uneducated upstream.