Git tag strategy in Squids GitHub repo

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Git tag strategy in Squids GitHub repo

Simon Staeheli
Hi there

We build Squid directly from its sources (https://github.com/squid-cache/squid.git) and not via the tar.gz from squid-cache.org . Is there a clear strategy how you guys use git tags? It looks like as there are some SQUID_4_0_X tags but they were never updated since Squid 4 became stable.

It would be awesome if there is tag pointing to every official Squid release.

Best
Simon
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git tag strategy in Squids GitHub repo

Amos Jeffries
Administrator
On 21/08/18 11:22 PM, Simon Staeheli wrote:
> Hi there
>
> We build Squid directly from its sources (https://github.com/squid-cache/squid.git) and not via the tar.gz from squid-cache.org . Is there a clear strategy how you guys use git tags? It looks like as there are some SQUID_4_0_X tags but they were never updated since Squid 4 became stable.
>
> It would be awesome if there is tag pointing to every official Squid release.
>

Formally each release is supposed to have a SQUID_N_N(_X) tag.

However, our auto-commit bot the QA team came up with does not do
tagging. And tags from third-party repositories (ie my release staging
one) are not imported by the github PR process.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Git tag strategy in Squids GitHub repo

Vacheslav


-----Original Message-----
From: squid-users <[hidden email]> On Behalf Of Amos Jeffries
Sent: Wednesday, August 22, 2018 6:06 AM
To: [hidden email]
Subject: Re: [squid-users] Git tag strategy in Squids GitHub repo

On 21/08/18 11:22 PM, Simon Staeheli wrote:
> Hi there
>
> We build Squid directly from its sources (https://github.com/squid-cache/squid.git) and not via the tar.gz from squid-cache.org . Is there a clear strategy how you guys use git tags? It looks like as there are some SQUID_4_0_X tags but they were never updated since Squid 4 became stable.
>
> It would be awesome if there is tag pointing to every official Squid release.
>

>Formally each release is supposed to have a SQUID_N_N(_X) tag.

>However, our auto-commit bot the QA team came up with does not do tagging. And tags from third-party repositories (ie my release staging
one) are not imported by the github PR process.

So Why not ask them to fix that?

>Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Git tag strategy in Squids GitHub repo

Amos Jeffries
Administrator
On 22/08/18 7:27 PM, Vacheslav wrote:

>
> -----Original Message-----
> From: Amos Jeffries
>
> On 21/08/18 11:22 PM, Simon Staeheli wrote:
>> Hi there
>>
>> We build Squid directly from its sources (https://github.com/squid-cache/squid.git) and not via the tar.gz from squid-cache.org . Is there a clear strategy how you guys use git tags? It looks like as there are some SQUID_4_0_X tags but they were never updated since Squid 4 became stable.
>>
>> It would be awesome if there is tag pointing to every official Squid release.
>>
>
>> Formally each release is supposed to have a SQUID_N_N(_X) tag.
>
>> However, our auto-commit bot the QA team came up with does not do tagging. And tags from third-party repositories (ie my release staging
> one) are not imported by the github PR process.
>
> So Why not ask them to fix that?
>

What makes you think I didn't do that most obvious of things?

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Git tag strategy in Squids GitHub repo

Vacheslav


-----Original Message-----
From: squid-users <[hidden email]> On Behalf Of Amos Jeffries
Sent: Wednesday, August 22, 2018 5:03 PM
To: [hidden email]
Subject: Re: [squid-users] Git tag strategy in Squids GitHub repo

On 22/08/18 7:27 PM, Vacheslav wrote:

>
> -----Original Message-----
> From: Amos Jeffries
>
> On 21/08/18 11:22 PM, Simon Staeheli wrote:
>> Hi there
>>
>> We build Squid directly from its sources (https://github.com/squid-cache/squid.git) and not via the tar.gz from squid-cache.org . Is there a clear strategy how you guys use git tags? It looks like as there are some SQUID_4_0_X tags but they were never updated since Squid 4 became stable.
>>
>> It would be awesome if there is tag pointing to every official Squid release.
>>
>
>> Formally each release is supposed to have a SQUID_N_N(_X) tag.
>
>> However, our auto-commit bot the QA team came up with does not do tagging. And tags from third-party repositories (ie my release staging
> one) are not imported by the github PR process.
>
> So Why not ask them to fix that?
>

>What makes you think I didn't do that most obvious of things?

Well the language you used is the one I use when I am talking about a resource which belongs to an enemy of mine!

>Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Git tag strategy in Squids GitHub repo

Alex Rousskov
In reply to this post by Amos Jeffries
On 08/21/2018 09:05 PM, Amos Jeffries wrote:
> On 21/08/18 11:22 PM, Simon Staeheli wrote:
>> It would be awesome if there is tag pointing to every official Squid release.

> our auto-commit bot the QA team came up with does not do tagging.

Very true. It also does not water plants.


> And tags from third-party repositories (ie my release staging
> one) are not imported by the github PR process.

True again and still irrelevant. GitHub does not import lightweight tags
when merging PRs because those tags are not a part of a PR branch and
are not supposed to be imported by git design.

GitHub certainly supports release tagging. The PR merging bot is not
(and probably should not be) responsible for releases, including release
tagging.

FWIW, in March 2018 email to Amos, I have already tried to explain the
design approach behind git tagging and offered a specific short-term
tagging solution. I did not get a response.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Git tag strategy in Squids GitHub repo

Vacheslav


-----Original Message-----
From: squid-users <[hidden email]> On Behalf Of Alex Rousskov
Sent: Wednesday, August 22, 2018 5:51 PM
To: [hidden email]
Subject: Re: [squid-users] Git tag strategy in Squids GitHub repo

On 08/21/2018 09:05 PM, Amos Jeffries wrote:
> On 21/08/18 11:22 PM, Simon Staeheli wrote:
>> It would be awesome if there is tag pointing to every official Squid release.

> our auto-commit bot the QA team came up with does not do tagging.

>Very true. It also does not water plants.


> And tags from third-party repositories (ie my release staging
> one) are not imported by the github PR process.

>True again and still irrelevant. GitHub does not import lightweight tags when merging PRs because those tags are not a part of a PR branch and are not supposed to be imported by git design.

>GitHub certainly supports release tagging. The PR merging bot is not (and probably should not be) responsible for releases, including release tagging.

>FWIW, in March 2018 email to Amos, I have already tried to explain the design approach behind git tagging and offered a specific short-term tagging solution. I did not get a response.

>Alex.

I get this all the time it's never me, it's everybody else who is out to get me :)
Like it wasn't the driver, the port on the switch was blocking, i.e I'm the innocent good guy!
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Git tag strategy in Squids GitHub repo

Simon Staeheli
In reply to this post by Simon Staeheli
> FWIW, in March 2018 email to Amos, I have already tried to explain the design approach behind git tagging and offered a specific short-term tagging solution. I did not get a response.

@Amos, according to squid-caches GitHub commit history it looks like as you are doing the releases. Would it be possible to come up with a proper git tagging solution?

Maybe the one proposed by Alex in March or even your own?
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git tag strategy in Squids GitHub repo

Amos Jeffries
Administrator
On 24/08/18 8:41 PM, Simon Staeheli wrote:
>> FWIW, in March 2018 email to Amos, I have already tried to explain the design approach behind git tagging and offered a specific short-term tagging solution. I did not get a response.
>

Ah, sorry I forgot or did not realize you were waiting on that.

The next opportunity I had for tagging the release checkouts was 4.2
which got tagged with SQUID_4_2 accordingly for PR 272.

As you can see that tag still does not exist in the master repository.


> @Amos, according to squid-caches GitHub commit history it looks like as you are doing the releases. Would it be possible to come up with a proper git tagging solution?
>

I am officially the maintainer, yes.


> Maybe the one proposed by Alex in March or even your own?
>

Alex "proposal" was to teach me about the git command line option(s) to
push tags to the repository. Which has worked fine .. for the repo I was
using. It has not helped with the public github one you are using.


The Anubis bot gateways all changes to the master repository - so to me
it seems like a reasonable place to be handling the issue of some PR
needing to be tagged as release. Especially since they have scripted
content that can be checked for.
 I'd rather have Anubis do the tagging than pulling in random tags from
any contributors repos.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Git tag strategy in Squids GitHub repo

Alex Rousskov
On 08/24/2018 05:50 AM, Amos Jeffries wrote:
> The next opportunity I had for tagging the release checkouts was 4.2
> which got tagged with SQUID_4_2 accordingly for PR 272.

> As you can see that tag still does not exist in the master repository.

Naturally. As I have tried to explain, tags are unrelated to GitHub PRs
and git branches. The official repository does not know what you tag in
your own repository, and GitHub cannot (correctly) automatically copy
tags between repositories because tags are independent names or objects
that can be (and often are!) specific to a repository.

FWIW, many projects use merge bots and protected GitHub branches. I have
not checked each project, so I am sure there are exceptions, but am not
aware of any of those projects tagging releases automatically. In fact,
the "gold standard" for tagging involves a human signing the tag! I am
not implying we must sign tags; this paragraph is only meant to
illustrate that what you think should be happening usually does not. The
previous paragraph (and my previous emails) explain that it probably
does not happen because it goes against git design.

As you know from my March email, GitHub actually has a web interface for
doing releases. Naturally, that functionality is based on tags. That
GitHub interface even allows you to tag a release! Again, I am not
saying we must use that interface or the underlying GitHub API. This
paragraph exists to provide one more example of releases/tagging being
treated separately from PRs and code commits. It also shows that you
have other tools to tag a release if you do not want to or cannot use
git command line.


> Alex "proposal" was to teach me about the git command line option(s) to
> push tags to the repository.

That was a small part of my email. A far more important (IMO) part was
about the nature of git tags. It looks like neither part had a desirable
effect.


> Which has worked fine .. for the repo I was using. It has not helped
> with the public github one you are using.

Why not? In other words, what did you do to push a tag from one
repository into another, and what happened when you did that? It is
difficult for me to help unless you tell me that you need help and
provide sufficient information to triage the problem.

Needless to say, you should experiment on unofficial repositories.


> The Anubis bot gateways all changes to the master repository

That assertion is incorrect. For example, Anubis does not (and IMO
should not) deal with branch creation and release tagging.


> - so to me it seems like a reasonable place to be handling the issue
> of some PR needing to be tagged as release.

Your suggestion to teach Anubis to tag releases is certainly reasonable.
However, I still think it is wrong to place a highly sensitive and
unrelated to PR merging act into a PR merging bot. Perhaps more
importantly, while we are discussing that suggestion, nothing stops you
from properly tagging all of the official releases now AFAICT.


> I'd rather have Anubis do the tagging than pulling in random tags from
> any contributors repos.

Me too, but that is a false dichotomy. The correct short-term solution
is, IMHO, to learn how to manually tag past official releases and tag them.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users