On Wed, Jun 24, 2015 at 12:32 AM, Pierre-Yves Chibon <pingou(a)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.