On Fri, Jun 26, 2015 at 09:33:21AM -0700, Gerald B. Cox wrote:
On Fri, Jun 26, 2015 at 9:18 AM, Remi Collet
This is exactly what I named "last solution".
Your proposal switch the Guidelines from
A A A A "must use hash commit"
toA A A "could use hash commit if no other solution exists,
A A A A but really you should try something else before"
First of all, the current guidelines do not say that you must use commit
my text doesn't at all say what you're implying.A You're reading in
simply isn't there.
It would be helpful if you could answer the questions I previously
they are again:
Why are you so concerned about theA use of Git Tags?A I have included
which clearly states that if the packagerA believes that re-tagging is
he MUST follow a specific procedureA to resolve that issue.A A
If there is a problem with the archive the checksumA
won't match. A The archive with the embedded commit information is already
in the srpm. A
The act of re-tagging can't change that.A We always know the commit hash
version of that archive. A What is the harm if we later find that upstream
Maybe because it kinda feels like shooting oneself in the foot: If you think
this will hurt, don't do it!
Well, no, let's just do the right thing first, the one we can rely on and just
not shoot ourselves in the foot to start with :)
The risk is also ending up with a situation where a bunch of packages are using
one approach, another bunch are doing something else, and yet a third bunch are
doing yet another way because of x, y, z.
Tags are a nice git features, but due to the nature of git itself, are a moving
Relying on it is not a wise thing to do.
You may understand the pros and cons, you may know that tags are moving target
but do not forget that we have a lot of people in community, including packagers
that are not developers. I think have one way of doing things and have this way
be the most secure one is better than offering multiple options left at the
discretion of people that may or may not have a deep understanding of the stake.