## Drop/Remaining Changes ##

I went through the old and new Delta one by one and side by side, I'll only mention the ones worth to talk about (Thanks for the changelog entries explaining drops/adds).

#1 on the "refresh patterns" I wonder, this carried over as it was.
But it also adds a pattern for  (Release|Packages(.gz)*) - probably worth to improve the changelog wording at least.
I'd have expected this to be commented out as well - do we want to change that?

#2 The "Correct attribution and add explanatory note in d/NEWS.debian" also is nor more relevant due to no related upgrade path being left. This can be Dropped IMHO.
Would you agree?

#3 "Set pidfile for systemd's sysv-generator" is no more needed. We have a native service which will be used (not the generator). This was from early Xenial and back then we had no service, so it made sense in the past, but no more.

#4 "short-circuiting"
It is important to note that this is in the maintscripts of the squid3 transitional package.
That transition already happened.
There is nothing generated after the removed short-circuit
The package is empty transitional now.
While in theory there could be something, there is in real life nothing in there.
The combination of "nothing is there" and "transition already happened" and "empty" makes me think we can drop this Delta - it isn't perfect in Debian, but also has no effect.
Turn it around, how would you explain Debian they need this Delta - see, there is no compelling reason I can think of.


Ack to all other Drops/Keep entries


## Added Changes ##
I checked debian/master - ack on the new changes themselve AND that are already in Debian and later to be dropped.

On the others:

#5 "d/t/0003-installed-binary-for-debian-ci.patch:  use the squid binary from the system"
I see what you are doing, why are we doing that?
Bug or minimal in changelog reasoning would be nice

#6 "Workaround gcc's maybe-unitialized" I know since I remember our discussion, but maybe add "ppc64el build issue" to the changelog for this?


I was confused why Debian has taken "fix apparmor profile filename" if we are the only ones adding the disabled profile?! I found there is an upstream profile in tools/apparmor/usr.sbin.squid but it is not installed.
Maybe as you said, just submit the disabled profile to Debian as well and be good with it.
Maybe OTOH a merge of our profile with the one from upstream would be better (submit our things upstream).
And finally I think best would be
a) bring our apparmor Delta to upstream
b) change Debian packaging to install that profile
That way we can actually benefit from what upstream is maintaining there - we can always add pacthes that extend it if needed.
This won't stall the upload, but being curious, is there more background to it already?

Ack on the other new changes.

## Fin ##
From a testing POV I haven't found anything that breaks - so good to go from that as well.
I tested manual upgrades, start/stop and the qa-regression tests.
The qa tests showed one issue, but I'll debug first if it is an issue in the test due to the rename.

Already great work and if you follow my reasoning even more cleanup will happen.
Eager to hear your opinion on it.