On Fri, Jun 26, 2015 at 1:11 PM, Gerald B. Cox <gbcox@xxxxxx> wrote:
>
>
> On Fri, Jun 26, 2015 at 9:44 AM, Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
>>
>> 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.
>
>
> Git Tags are not a moving target. Just because some people are abusing them doesn't
> mean we ban that functionality. The Draft guideline addresses clearly what to do if you
> believe someone is engaging in re-tagging. The current guideline is silent.
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.
The wording of the comment for re-tagging upstreams is also pretty
onerous:
# Upstream is known to engage in the practice of Re-tagging
# and was notified on dd-mm-yyyy that this is not allowed.
# Full commit hash is being used since they have not
# corrected the situation.
Yikes. Not allowed by whom? Is Fedora now the git police? Does an
upstream even care what Fedora thinks of its policies? In the end,
it's worth making best practice suggestions to upstream if their
moving tags is causing problems for the packager, but I don't think
it's worth dropping useful software from the distribution or pasting
violation notices in our spec files for something as trivial as a
disagreement over git best practices.
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?
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
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.
> 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. 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.
Rich
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
