[squid-dev] RFC submodule repositories

[Amos Jeffries]

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