[squid-dev] Squid-4 release checklist

[Alex Rousskov]

On 09/13/2016 12:02 AM, Amos Jeffries wrote:
> 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
> ... 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.

I have no problems with what you are saying now. I still have problems
with downgrading bug severity level if nobody can reproduce. Perhaps
your "downgrade" means something else or perhaps we are using different
strategies to defining what bug importance/severity field represents.
More on that below.


> The severity rating for the project needs to be
> estimated/determined by how widely it can be expected to affect the
> Squid community.

Please note that I was and still am discussing specific bug metadata,
such as the importance/severity rating field, not any derived metrics.

There are at least two strategies when dealing with the
importance/severity rating field:

* Adjusting severity rating based on the bug spread is a valid strategy.

* The alternative strategy is to separate severity from "reproducibility
in multiple environments". I favor this strategy because it is simpler
and because it reduces tensions between those who suffer from the bug
and those who maintain bug metadata.


With _either_ strategy, when it comes to deciding what to do about the
bug as far as marking Squid branch as stable is concerned, it is too
easy and too convenient for us to misinterpret the absence of "me too"
bug comments as a sign that a bug spread is narrow. Folks suffering from
these bugs may not read your squid-dev post implicitly threatening them
to "ignore" the bugs they are suffering from. I am not saying there are
such folks for this particular bug. I am saying that the approach itself
is dangerous. To reduce that danger, we should be posting these warnings
to squid-users (and to each affected bug report).


>>> * <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?

Nobody has proposed to penalize the whole world. I am objecting to
adjusting bug metadata (your "downgrading") without sufficient grounds
for doing so. I am _not_ objecting to ignoring that bug for the purpose
of assigning various labels to Squid branches (with sufficient grounds
for doing so). The two actions are very different IMO.

The "context" bullets you provide can be the reasons to ignore this bug
while deciding whether to mark v4.0 as stable. They are not the reasons
to change bug metadata (using the metadata maintenance strategy I
recommend, as discussed above).


>>> * <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.

You are changing the goal posts: It was "nobody intends to work on it"
but now you are saying "nobody suffers from it". My earlier comment
naturally applies to the former goal posts.

As for the new "no noticeable issues" argument, it is even weaker than
the "nobody said they can reproduce it" argument discussed earlier! This
bug does exist in nearly all supported SMP caching environments. Like
many caching bugs, "noticing" this issue is difficult and narrowing it
down enough for a quality bug report requires analysis that most admins
cannot perform, but it is a rather serious HTTP (cache integrity) violation.

Again, you may decide to ignore this bug for the purpose of declaring
v4.0 as stable. However, you need a different reason for doing so. For
example, you can claim that the bug affects v3.5 as well.

Nobody can stop you from marking v4.0 as stable because the existing
formal stability requirements are very weak, but let's not upset users
even more and screw up bug management in the process: These negative
side effects are simply not necessary, and we will have more than enough
other negative side effects to deal with after v4.0 is pronounced stable!


Thank you,

Alex.