On Wed, Mar 22, 2023 at 12:10:56AM +0100, Daniel Stenberg wrote:
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.
That's a good way of looking at it! On a related note, what's the
current code coverage? I haven't tried myself in a looong time, and
there hasn't been a Coveralls build in 5 years. That would be a great
graph to see on https://curl.se/dashboard.html But with all the
different build configurations it would be hard to get a single
meaningful number out of it; maybe that's why it hasn't happened since
then.
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.
My idea was to continue development in master as normal, but if
something comes up that necessitates a point release, a point branch
would be created and only the relevant commits would be cherry-picked
from master into it. There would be nothing new in such a branch so
people wouldn't need to look at it to figure out development history.
But, you're right, you wouldn't be able to just run git log and search
for the point release tags any more. IIRC, there's at least one point
release in curl's history like that already.
Or we don't do different branches because the testing would be too
difficult to handle.
We can configure most (all?) of the CI services to run on specific
branches, so we should be able to have testing happen automatically on
point branches. Worst case, someone would need to create a dummy PR
before release, wait for the results then delete the PR. Not nice, but
probably also not necessary.
like we would basically not merge lots of things into the master
branch for several weeks after a release. Also not ideal.
That would definitely slow the pace of development too much.
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.
That might be enough of a change to improve things. It's a minimal tweak
to the existing workflow but with the improvement that more people get
to eventually benefit from the quiet period after a release.
I am a bit worried about the point Timothe brings up that if too many
people (especially distributions) skip the regular releases and just
wait for the point release, problems won't be found in time and people
won't get a more stable point release. Still, that's really no worse
than the place we're in now so it shouldn't stop us from trying.
Dan
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
