Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: noproxy breakage
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Thu, 27 Oct 2022 18:07:57 -0400
On 27-Oct-22 17:42, Randall via curl-library wrote:
> On October 27, 2022 5:30 PM, Daniel wrote:
>> A regression in the noproxy filter functionality in 7.86.0 has been
> suggested to be
>> reason enough for a patch release:
>>
>> https://github.com/curl/curl/issues/9813
>>
>> We don't yet have any stated policy for how to judge when a bug is reason
>> enough for a patch release but maybe this is the time to try to forumlate a
>> guideline?
> As a starting point, a common set of guidelines for justifying patch
> releases include the following non-conflicting requirements:
>
> 1. Is there a high rated security advisory for which a fix is available?
> 2. Is there a data corruption during processing for which a fix is
> available?
> 3. Is there a stack corruption that causes the software to prematurely
> terminate for which a fix is available?
> 4. Does the fix not change any API, which would exclude a patch-level
> release.
> 5. Is the fix of general applicability instead of one environment, OS
> release, or platform?
> 6. Is there a malware attack vector that can be closed with an available
> patch?
>
> Just my off-the-cuff dump of what I have used on other projects for patch
> release justification.
>
> -Randall
>
This is a good list. Some additional considerations:
* What is the scope/risk of the patch?
* What else is pending? Sometimes it's worth waiting for more
experience (with the release and the patch) to avoid multiple patch
releases, especially close together.
* What is the best delivery method - a patch or a full release?
* Is there a work-around that has acceptable impact to the users?
(now, and when the fix is released)
* Is this a regression, or a newly-discovered issue? The hurdle for
the latter triggering a release is higher (but not infinite).
* Is the patch a work-around, or the final solution?
* What's impact on the project? (How many reports? Is it blocking
adoption of the release?)
* How many users are actually impacted? Are any critical to the
project, or severely impacted?
Attempts to have a mechanical scorecard for a decision are rarely
successful, but thinking about the issues is worthwhile.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2022-10-28
Date: Thu, 27 Oct 2022 18:07:57 -0400
On 27-Oct-22 17:42, Randall via curl-library wrote:
> On October 27, 2022 5:30 PM, Daniel wrote:
>> A regression in the noproxy filter functionality in 7.86.0 has been
> suggested to be
>> reason enough for a patch release:
>>
>> https://github.com/curl/curl/issues/9813
>>
>> We don't yet have any stated policy for how to judge when a bug is reason
>> enough for a patch release but maybe this is the time to try to forumlate a
>> guideline?
> As a starting point, a common set of guidelines for justifying patch
> releases include the following non-conflicting requirements:
>
> 1. Is there a high rated security advisory for which a fix is available?
> 2. Is there a data corruption during processing for which a fix is
> available?
> 3. Is there a stack corruption that causes the software to prematurely
> terminate for which a fix is available?
> 4. Does the fix not change any API, which would exclude a patch-level
> release.
> 5. Is the fix of general applicability instead of one environment, OS
> release, or platform?
> 6. Is there a malware attack vector that can be closed with an available
> patch?
>
> Just my off-the-cuff dump of what I have used on other projects for patch
> release justification.
>
> -Randall
>
This is a good list. Some additional considerations:
* What is the scope/risk of the patch?
* What else is pending? Sometimes it's worth waiting for more
experience (with the release and the patch) to avoid multiple patch
releases, especially close together.
* What is the best delivery method - a patch or a full release?
* Is there a work-around that has acceptable impact to the users?
(now, and when the fix is released)
* Is this a regression, or a newly-discovered issue? The hurdle for
the latter triggering a release is higher (but not infinite).
* Is the patch a work-around, or the final solution?
* What's impact on the project? (How many reports? Is it blocking
adoption of the release?)
* How many users are actually impacted? Are any critical to the
project, or severely impacted?
Attempts to have a mechanical scorecard for a decision are rarely
successful, but thinking about the issues is worthwhile.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature