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: On more stable curl releases
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 22 Mar 2023 08:41:55 +0100
> Am 22.03.2023 um 00:10 schrieb Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>:
>
> On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
>
>> Some examples of regressions would be the crash that prompted yesterday's 8.0.1 point release, the noproxy host matching bug #9842 (fixed in 7.86.0) and the wrong units bug in --write-out %{time_total} (fixed in 7.75.0). Of these three examples, one resulted in a point release while the other two did not.
>
> BTW, "regression" is just another word for "test coverage gap", since if we had tested the thing we would've detected the problem and the bug would not have been shipped. It is important that we learn from the regressions and improve the tests every time.
Yes, test coverage for regressions is the only thing that works *and* allows us to evolve.
>
>> To look at it another way, between tags 7.75.0 and 7.88.1 (17 versions of commits), 32 commits say "regression" in the comment, averaging 1.9 regressions per release.
>
> That is probably counting low since we don't always highlight them being regressions. Also, a regression can of course be something that *once* worked but that does not necessarily mean that it worked in the most previous release. It can also be five years ago.
>
>> I would like to see patch releases more often that include fixes that target regressions.
>
>> A point release would only contain regression fixes and other fixes deemed low risk.
>
> I agree that we do ship a certain rate of regressions and we fix them in subsequent releases.
>
> I understand your thinking with your proposal, but I am scared of going that route: because either we need to do the patch release management in a separate branch, so that we can allow the main branch to merge features for the next feature release and then we get a huge test and maintenance challenge: meaning we need to do everything that in two branches. Gone are the days of simple git history.
Speaking from experience in Apache httpd, release branch costs are considerable.
> Or we don't do different branches because the testing would be too difficult to handle. Then we need to handle this in the main branch and then it seems like we would basically not merge lots of things into the master branch for several weeks after a release. Also not ideal.
>
> I instead propose this much smaller and simpler change:
>
> We lower the bar for doing follow-up patch releases for regressions reported already within the period between the release and the re-opening of the feature window. For such we can do another release again already within a week or two. It is usually good to not stress them too much since then we get the chance to also find and fix other issues in the patch release.
Delaying the opening of the feature window after a release seems to be a good balance. Right now, I have several PRs pending for the re-opening of the window and it does not cost anything to have them wait a week more. Feature branches already exist. Maintenance branches we'd like to avoid.
Kind Regards,
Stefan
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Date: Wed, 22 Mar 2023 08:41:55 +0100
> Am 22.03.2023 um 00:10 schrieb Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>:
>
> On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
>
>> Some examples of regressions would be the crash that prompted yesterday's 8.0.1 point release, the noproxy host matching bug #9842 (fixed in 7.86.0) and the wrong units bug in --write-out %{time_total} (fixed in 7.75.0). Of these three examples, one resulted in a point release while the other two did not.
>
> BTW, "regression" is just another word for "test coverage gap", since if we had tested the thing we would've detected the problem and the bug would not have been shipped. It is important that we learn from the regressions and improve the tests every time.
Yes, test coverage for regressions is the only thing that works *and* allows us to evolve.
>
>> To look at it another way, between tags 7.75.0 and 7.88.1 (17 versions of commits), 32 commits say "regression" in the comment, averaging 1.9 regressions per release.
>
> That is probably counting low since we don't always highlight them being regressions. Also, a regression can of course be something that *once* worked but that does not necessarily mean that it worked in the most previous release. It can also be five years ago.
>
>> I would like to see patch releases more often that include fixes that target regressions.
>
>> A point release would only contain regression fixes and other fixes deemed low risk.
>
> I agree that we do ship a certain rate of regressions and we fix them in subsequent releases.
>
> I understand your thinking with your proposal, but I am scared of going that route: because either we need to do the patch release management in a separate branch, so that we can allow the main branch to merge features for the next feature release and then we get a huge test and maintenance challenge: meaning we need to do everything that in two branches. Gone are the days of simple git history.
Speaking from experience in Apache httpd, release branch costs are considerable.
> Or we don't do different branches because the testing would be too difficult to handle. Then we need to handle this in the main branch and then it seems like we would basically not merge lots of things into the master branch for several weeks after a release. Also not ideal.
>
> I instead propose this much smaller and simpler change:
>
> We lower the bar for doing follow-up patch releases for regressions reported already within the period between the release and the re-opening of the feature window. For such we can do another release again already within a week or two. It is usually good to not stress them too much since then we get the chance to also find and fix other issues in the patch release.
Delaying the opening of the feature window after a release seems to be a good balance. Right now, I have several PRs pending for the re-opening of the window and it does not cost anything to have them wait a week more. Feature branches already exist. Maintenance branches we'd like to avoid.
Kind Regards,
Stefan
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-03-22