On Fri, Jun 26, 2015 at 10:49 AM, Rich Mattes <richmattes@xxxxxxxxx> 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.
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
