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: ngtech1...@gmail.com Web: https://ngtech.co.il/ My-Tube: https://tube.ngtech.co.il/ -----Original Message----- From: squid-dev <squid-dev-boun...@lists.squid-cache.org> On Behalf Of Amos Jeffries Sent: Tuesday, 2 August 2022 5:32 To: squid-dev@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@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
