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@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
