On Thu, 23 Mar 2023, Daniel Stenberg via curl-library wrote:
Another adjustment to the cycle I think we can do is to even out the feature
window and the feature freeze periods a little. A full three weeks for new
features:
PR proposal here: https://github.com/curl/curl/pull/10827
--
/
On Wed, 22 Mar 2023, Daniel Stenberg via curl-library wrote:
- Increase the post-release ("cool down") margin before we open the feature
window. We currently have it 5 days, we could double it to 10 days. That
would then reduce the feature window with the same amount of days leaving
us
On Wed, Mar 22, 2023 at 04:10:32PM -0700, bch via curl-library wrote:
> This is a curl binary, or a release tarball
The daily tar balls are available at https://curl.se/snapshots/
> (how much processing *does* go on
> from a repo checkout -> curl-x.y.z.tar.gz?)?
I think it's just running
On Wed, Mar 22, 2023 at 00:34 Daniel Stenberg via curl-library <
curl-library@lists.haxx.se> wrote:
> On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
>
> > It would be great if we can find more people to test pre-release curl
> > versions
>
> I believe that is the holy grail we can only
On Wed, 22 Mar 2023, Jeffrey Walton wrote:
To counter the lack of pre-release testing, schedule another release
T+x days after the release of interest.
The point of the "cool down" period after a release is to allow that
*possibility*. We can do it if we feel we need to.
In the projects I
On Wed, 22 Mar 2023, Dan Fandrich via curl-library wrote:
The last two changes fix compile problems in two platforms, OS/400 and Haiku.
Normally, I'd say that would be enough to trigger another release: users can't
build curl when they used to be able to, but these are super marginal
platforms.
On Wed, Mar 22, 2023 at 09:17:48AM +0100, Daniel Stenberg via curl-library
wrote:
> So, how about this for adjusted release cycle and release management:
>
> - Increase the post-release ("cool down") margin before we open the feature
>window. We currently have it 5 days, we could double it
On Wed, Mar 22, 2023 at 4:17 AM Daniel Stenberg via curl-library
wrote:
>
> On Wed, 22 Mar 2023, Stefan Eissing wrote:
>
> > 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
W dniu 2023-03-22 13:46, Daniel Stenberg napisał(a):
On Wed, 22 Mar 2023, Daniel F via curl-library wrote:
One option is to provide coverage data for each platform/test job,
plus one extra created by merging results from all platform. With this
approach you could check if there are any code
On Wed, 22 Mar 2023, Daniel F via curl-library wrote:
One option is to provide coverage data for each platform/test job, plus one
extra created by merging results from all platform. With this approach you
could check if there are any code paths which are not tested at all by
checking merged
W dniu 2023-03-22 08:45, Daniel Stenberg via curl-library napisał(a):
On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
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
On Wed, 22 Mar 2023, at 08:17, Daniel Stenberg via curl-library wrote:
> So, how about this for adjusted release cycle and release management:
>
> - Increase the post-release ("cool down") margin before we open the feature
> window. We currently have it 5 days, we could double it to 10
On Wed, 22 Mar 2023, Kamil Dudka wrote:
If you look at the recent pull requests, you could hardly find one with
green CI.
Ah right, yes. Good point.
This is also one of the reasons for regressions: our flaky CI setup makes it
too easy to sometimes miss test failures because we have to live
On Wednesday, March 22, 2023 8:34:30 AM CET Daniel Stenberg via curl-library
wrote:
> On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
>
> > It would be great if we can find more people to test pre-release curl
> > versions
>
> I believe that is the holy grail we can only dream of.
On Wed, 22 Mar 2023, Stefan Eissing wrote:
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.
On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
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
> Am 22.03.2023 um 00:10 schrieb Daniel Stenberg via curl-library
> :
>
> 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)
On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
It would be great if we can find more people to test pre-release curl
versions
I believe that is the holy grail we can only dream of. People are simply
hesitant to try pre-releases. Granted, we haven't tried this for a long time
but
> From: curl-library On Behalf Of Dan
> Fandrich via curl-library
> Sent: Wednesday, 22 March 2023 05:33
> To: curl-library@lists.haxx.se
> Cc: Dan Fandrich
> Subject: Re: On more stable curl releases
>
> Maybe we should label the daily snapshot one week before a
>
On Tue, Mar 21, 2023 at 12:40:28PM -0400, Timothe Litt via curl-library wrote:
I expect that with frequent patch releases, curl would end up in the situation
of most M$ releases whose strategy is- "wait for the other people to find the
bugs and only take the nth patch release." And with fewer
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
Daniel Stenberg via curl-library writes:
> 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
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
I agree with the problem statement. But there's no easy answer.
I expect that with frequent patch releases, curl would end up in the
situation of most M$ releases whose strategy is- "wait for the other
people to find the bugs and only take the nth patch release." And with
fewer users, the
I've been getting a feeling that there have been more curl functional
regressions (compared to plain bugs) in releases over the last few years. I
don't know if that's true or not, but the pace of bug fixes generally has been
going up (see https://curl.se/dashboard1.html#bugfix-frequency). I'm
25 matches
Mail list logo
