[squid-dev] RFC submodule repositories

[ngtech1ltd at gmail.com]

Hey Amos,

I believe we are trying to benefit something from the updates.
CERN have been using my packages for a very long time now.
But as you can see their updates are at:
http://linuxsoft.cern.ch/mirror/

and it states latest update at 2019 so they have not upgraded their mirror for at-least 2-3 years now and I believe that they can stand by them self.
I am merely packaging for who ever needs it.
>From my point of view there are core helpers and deprecates helpers.
For example ssl_crtd is one of the squid core helpers for couple groups for a very long time now.

I can try to pack squid helpers as a stand alone package given that I will have something like what you suggest.

We can try to make a list of the helpers and suggest a pass vote per each of them.

Eliezer

----
Eliezer Croitoru
NgTech, Tech Support
Mobile: +972-5-28704261
Email: ngtech1ltd at gmail.com
Web: https://ngtech.co.il/
My-Tube: https://tube.ngtech.co.il/

-----Original Message-----
From: squid-dev <squid-dev-bounces at lists.squid-cache.org> On Behalf Of Amos Jeffries
Sent: Tuesday, 2 August 2022 5:32
To: squid-dev at lists.squid-cache.org
Subject: Re: [squid-dev] RFC submodule repositories

On 1/08/22 03:09, Alex Rousskov wrote:
> On 7/31/22 00:29, Amos Jeffries wrote:
>> When PR #937 merges we will have the ability to shuffle old helpers 
>> into a separate repository that users can import as a submodule to 
>> build with their Squid as-needed.
> 
> In my experience, git submodules are a powerful feature that is rather 
> difficult to use correctly. Some of submodule aspects do not feel 
> "natural" to many humans. I am pretty sure that proper introduction of 
> submodules will require a lot of our time and nerve cells. What will we 
> optimize by introducing such a significant complication as git submodules?
> 


( So every change to Squid has to be justified as an optimization now. 
Right... )

We "optimize" future code maintenance workload with the ability to drop 
outdated helpers which are still required by a small group of users but 
no longer want to be actively developed by the core dev team.

Case in point being CERN who still require our bundled LanManager 
helper(s) for some internal needs. That requires a lot of deprecated and 
rarely touched code being maintained for only one (albeit important) 
user case.
  That code could all be shuffled to a separate repository outside the 
official Squid release, but maintained by developers that support CERN 
needs.


> 
>> What (if any) updates do we need to make to Anubis and other 
>> infrastructure so support git submodules ?
> 
> That answer probably depends, in part, on what support guarantees we are 
> going to issue for those submodules and on what our submodule update 
> policy will be. Integrating two or more git repositories together is a 
> complicated issue...
> 

IMO we should maintain at least one helper officially as a submodule to 
ensure the git submodule mechanisms remain viable for distributors as a 
modern replacement for the old squid-2 way of building their custom helpers.


Cheers
Amos
_______________________________________________
squid-dev mailing list
squid-dev at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev