[squid-dev] Squid-4 release checklist

Amos Jeffries squid3 at treenet.co.nz
Tue Sep 13 06:02:12 UTC 2016


On 13/09/2016 6:22 a.m., Alex Rousskov wrote:
> On 09/12/2016 09:54 AM, Amos Jeffries wrote:
> 
>> * <http://bugs.squid-cache.org/show_bug.cgi?id=4514>
>>   Windows Update works via interception ptoxy on 3.5.17, and no works
>> via transparent proxy on Squid 4.x.
>>
>>  - FWIW; others have been mentioning various issues with various Squid
>> versions ever since Windows 10 came out.
>>  - I am inclined to downgrade this unless someone can reproduce it.
> 
> Why "downgrade"? The importance of a bug should not go _down_ after
> confirming (or assuming) that the bug affects several Squid versions.

Agreed, which is why that second statement. IF someone can reproduce -
the description seems clear enough to do so with a Windows network
setup. Then its a major bug (affecting many people using Squid),
otherwise it is limited to the one network which other evidence shows is
broken in many ways down to and below the TCP level. It might even be
fixed already for all we can tell.


> You might ignore the old bug for the purpose of assigning various labels
> to Squid branches, but downgrading it for that reason seems inappropriate.
> 

Almost every bug is a major/critical/blocker issue for those noticing
its affects. The severity rating for the project needs to be
estimated/determined by how widely it can be expected to affect the
Squid community.


>> * <http://bugs.squid-cache.org/show_bug.cgi?id=4497>
>>   CloudFlare and hosted sites cannot be connected via SSL\TLS(with DH)
>> with NONE/503
>>
>>  - stuck waiting sufficient information to identify what the problem
>> actually is. The traces we have so far indicate the network in question
>> is very noisy with TCP packet retries, duplications, checksum errors,
>> and outright delivery failures.
>>  - I am inclined to downgrade unless anyone else is able to reproduce
>> the issue.
> 
> Downgrading because others cannot reproduce seems inappropriate.
> Treating the bug as UNCONFIRMED would the right cause of action if
> nobody but Yuri can confirm it. The current MOREINFO state can also be
> used as an excuse to ignore this bug for the purpose of assigning
> various labels to Squid branches *if* you think that there is actually
> no bug there (and that getting more info will only confirm that).
> 

Some context:
* only affecting one person AFAIK,
* on a network with visibly borked TCP layer,
* running proxy on a uncommon proprietary OS (Solaris),
* with custom patches IIRC,
* person has a history of reporting almost all bugs as
blocker/critical/major to get attention,
* person has a history of actively inhibiting bug resolution when
frustrated by progress.

Why penalize the whole world for one admins somewhat unusual conditions?

Given the above context I am doubting the bugs severity rating is
anywhere near accurate in regards to what the wider community will see.
But it still needs 'more info' or replication.


> 
>> * <http://bugs.squid-cache.org/show_bug.cgi?id=4505>
>>   Memory hits shadow disk entries and vice versa
>>
>>  - will downgrade unless someone intends to work on it.
> 
> Downgrading bug severity because nobody is working on a fix is wrong.
> 

It is on the choppign block for downgrade because AFAIK it has not been
causing noticable issues to those currently using Squid-4.


> Please note that Eduard is working on fixing that bug, and the bug
> metadata (i.e., the Assignee field) reflects that fact (to the extent
> our Bugzilla can reflect it). We are on the tenth patch revision, but
> are probably approaching usable state.
> 

Great. :-)


Amos



More information about the squid-dev mailing list