<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 10:49 AM, Rich Mattes <span dir="ltr"><<a href="mailto:richmattes@gmail.com" target="_blank">richmattes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1dl" class="" style="overflow:hidden">The best practices for using git aren't going to be universally<br>
applied by all upstreams. They're just not. People make mistakes,<br>
people decide to do things their own way, and I don't think it's our<br>
responsibility or problem as Fedora packagers to police upsteams for<br>
git tagging like it is for more important things like LICENSE files.<br>...<br>
<br>
Yikes. Not allowed by whom? Is Fedora now the git police? Does an<br>
upstream even care what Fedora thinks of its policies? </div></blockquote><div><br></div><div>ROFL...Rich, excellent point. I put that in because there had been some </div><div>feedback concerning re-tagging. If we're going to do something about it</div><div>I think it is more helpful to try to educate upstream than to just issue</div><div>a blanket ban in Fedora. I have no problem whatsoever in changing that </div><div>instruction. I do think it is helpful to put into the Spec file some type of</div><div>comment that a particular upstream is re-tagging, if we believe it is worthwhile.</div><div>I'm still trying to understand the real harm to Fedora if somehow a re-tagged</div><div>package slips through. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1dl" class="" style="overflow:hidden"><br>
The biggest complaint I have with this draft is that it introduces a<br>
lot of extra unnecessary work for packagers. Anyone packaging<br>
software coming from a git repository first has to figure out if<br>
they're able to use tags or not, based on a very opaque criteria. How<br>
do you know that a project is moving tags? Can you audit it before<br>
you package it? How much work does that take? Further, once you do<br>
package something, how do you make sure that the tag you used in your<br>
source URL doesn't change? Do you need to check your source checksum<br>
vs upstream when making point releases? Or do you check it monthly or<br>
weekly? Is there any way to automate this process for people that<br>
maintain a lot of packages?<br></div></blockquote><div><br></div><div>Good point, again, I put that text in there because some people were concerned</div><div>about the harm to Fedora with re-tagging. I believe this would mainly come up</div><div>in the package review process, you would know if someone had re-tagged because</div><div>the checksum wouldn't match when fedora-review did the check. Yes, that</div><div>would only be for that point in time. It wasn't my intent to have the packager</div><div>continually audit to check for re-tagging.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1dl" class="" style="overflow:hidden">
The current guidelines are good for a number of reasons, including<br>
* There is **one** way to get releases from github<br>
* There are code snippets to copy/paste to make life easier<br>
* The rpm source URL will ALWAYS point to the code you used to generate the RPM<br>
<br></div></blockquote><div>That still holds true in my Draft; but it makes clear that we're talking about Git, not just</div><div>GitHub.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1dl" class="" style="overflow:hidden">
I don't think your proposed guidelines are an improvement to the<br>
current guidelines. They're creating a lot of extra work and<br>
complexity just to make things look nicer in some cases.<br></div></blockquote><div><br></div><div>My intent was to clarify the current guidelines and bring them up-to-date and clear</div><div>up some misleading statements. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1dl" class="" style="overflow:hidden">
<span class=""><br>
> As I mentioned previously, the commit hash is part of the generated archive. That information<br>
> is never lost, regardless of what upstream does with the Git Tag.<br>
<br>
</span>How are you generating archives? If you generate them with a url like<br>
<a href="http://github.com/$USER/%{name}/archive/%{name}-%{tag}.tar.gz2" rel="noreferrer" target="_blank">github.com/$USER/%{name}/archive/%{name}-%{tag}.tar.gz2</a><div style="display:inline-block;width:16px;height:16px"> </div>, then there's<br>
no commit hash anywhere in the archive (at least that I can see.) If<br>
you're generating the archives a different way, you need to include an<br>
example of how to do so in your guideline draft. </div></blockquote><div> </div><div>You obtain the commit hash via git get-tar-commit-id < $tar_file_name</div><div>Remember to execute this command against the tar file and not the compressed archive.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1dl" class="" style="overflow:hidden">The "Git Tags"<br>
section of the draft provides no guidance for how to actually assemble<br>
a source URL from a git tag. It just says that tags can be formatted<br>
differently project to project, and then goes on to talk about tags<br>
moving.</div></blockquote><div><br></div><div>I thought it was intuitive and didn't need an example... but I have no problem whatsoever</div><div>with adding an example if folks think it would be helpful. </div></div><br><br></div></div>