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