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 <Fedora@xxxxxxxxxxxxxxxxx> > wrote: > > 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" > > A > First of all, the current guidelines do not say that you must use commit > hash, and > my text doesn't at all say what you're implying.A You're reading in > something that > simply isn't there. > It would be helpful if you could answer the questions I previously > asked.A HereA > they are again: > Why are you so concerned about theA use of Git Tags?A I have included > textA > which clearly states that if the packagerA believes that re-tagging is > being used,A > 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 > did re-tag? 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 target. 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. Pierre -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
