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.