Re: patch release tomorrow

[K. Frank]

Hello Steve and Daniel!

On Mon, Aug 8, 2016 at 2:43 PM, Steve Holme  wrote:
> On Sun, 7 Aug 2016, Daniel Stenberg wrote:
> ...
> I understand your view point and I won't argue with that - its half a dozen
> of one and 6 of the other in my opinion.

Which weighs more, Steve?  Six dozen dozen pounds of feathers, or
half a dozen dozen pounds of lead?

>> Tricky.
>
> I did say it was subjective ;-)

(Sorry ...   I couldn't resist.)


Happy Hacking!


K. Frank
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Re: patch release tomorrow

[Dan Fandrich]

On Tue, Aug 09, 2016 at 12:13:02PM +0200, Daniel Stenberg wrote:
> On Tue, 9 Aug 2016, Dan Fandrich wrote:
> 
> >I wouldn't mind seeing CURL_STRICTER set automatically whenever
> >CURL_NO_OLDIES is set. The latter is used by people to ensure that their
> >code is forward-compatible with libcurl and the CURL_STRICTER changes
> >really fall into the same bucket.
> 
> I agree, I think that is totally sensible. Maybe just like this:
> 
> --- a/include/curl/curl.h
> +++ b/include/curl/curl.h
> @@ -28,10 +28,14 @@
>   *
>   * curl-library mailing list subscription and unsubscription web interface:
>   *   https://cool.haxx.se/mailman/listinfo/curl-library/
>   */
> 
> +#ifdef CURL_NO_OLDIES
> +#define CURL_STRICTER
> +#endif
> +
> 

Looks fine to me. The down side of being unable to enable CURL_NO_OLDIES but
not CURL_STRICTER seems unimportant given that any application could be fixed
to work with CURL_STRICTER.

>>> Dan
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Re: patch release tomorrow

[Daniel Stenberg]

On Tue, 9 Aug 2016, Dan Fandrich wrote:

I wouldn't mind seeing CURL_STRICTER set automatically whenever 
CURL_NO_OLDIES is set. The latter is used by people to ensure that their 
code is forward-compatible with libcurl and the CURL_STRICTER changes really 
fall into the same bucket.


I agree, I think that is totally sensible. Maybe just like this:

--- a/include/curl/curl.h
+++ b/include/curl/curl.h
@@ -28,10 +28,14 @@
  *
  * curl-library mailing list subscription and unsubscription web interface:
  *   https://cool.haxx.se/mailman/listinfo/curl-library/
  */

+#ifdef CURL_NO_OLDIES
+#define CURL_STRICTER
+#endif
+


--

 / daniel.haxx.se
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Re: patch release tomorrow

[Dan Fandrich]

On Tue, Aug 02, 2016 at 11:27:17PM +0200, Daniel Stenberg wrote:
> On Tue, 2 Aug 2016, Richard Gray wrote:
> >>Possibly most notable: we're reverting the change that modified the
> >>CURL, CURLM and CURLSH types and they go back to be 'void *' unless you
> >>define CURL_STRICTER before including our headers.
> >
> >I wonder if there's an itch that wants to be scratched in terms of a
> >curl_lite.h or #define CURL_MINIMAL or something...
> 
> Maybe. But I prefer not to act on something like that until we get someone
> who actually have that itch come here and advocate for something like that
> so that we A) are sure there truly are people who want and would use
> something like that and B) we would do it in a way that would accurately
> scratch the itches of such people...

I wouldn't mind seeing CURL_STRICTER set automatically whenever CURL_NO_OLDIES
is set. The latter is used by people to ensure that their code is
forward-compatible with libcurl and the CURL_STRICTER changes really fall into
the same bucket.

>>> Dan
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

RE: patch release tomorrow

[Steve Holme]

On Sun, 7 Aug 2016, Daniel Stenberg wrote:
> > I also appreciate this is a little subjective but I would have thought 
> > adding support for NTLM with mbedTLS is also a new functionality - 
> > previously NTLM wasn't supported with mbedTLS so I wouldn't class that as a 
> > bug fix.
> 
> That's of course a matter of defintion and while it perhaps isn't strictly a 
> bug that was fixed, since it was very much deliberate. But I consider it a 
> bug 
> when a particualr backend doesn't support the full feature set so when we fix 
> that it is a bug fix. I don't view it as a real "change" either since 
> supporting NTLM is something we've done for decades.
I understand your view point and I won't argue with that - its half a dozen of 
one and 6 of the other in my opinion.
> Tricky.
I did say it was subjective ;-) 
> > It seems to me that, those 4 weeks of testing and bug fixing aren't going 
> > to 
> > be used as well as they could be. With regards to testing there hasn't been 
> > much added since the last weeks release so not a huge amount of stuff to 
> > test.
> 
> I beg to differ. We're constantly behind on bug fixing (and associated tests) 
> so even without anything added we still have lots of things to fix and test. 
> Just see the KNOWN_BUGS and the open issues. Several of those have been 
> around 
> for a long time and I struggle to keep up.
I know the bugs are building up and sorry for not being around lately. For what 
it's worth I have a fix for Kerberos 5 (GSS-API) authentication being selected 
and failing when no domain selected but I need to push it in two parts. 
However, I'm not sure I have my HTTP logic correct yet so need to retest that 
and not found the time the last couple of weekends :(
> I would agree that we're probably not that many people doing this kind of 
> debug and test work, so the bugfixing period may actually be taken by some 
> (or 
> many) as a hint to go procrastinate until the feature window opens again but 
> I'm not sure that's a very good argument for us to change habits.
You knew where I was coming from with that ;-)
> >> So, do you or anyone else want another week for adding features until we 
> >> close that for the next release?
> >
> > Please - and it the chance for other features to drop in as well.
> 
> Absolutely! The feature window is hereby extended one week - it'll now close 
> on August 17. Let's try to keep the pending release date at September 7th 
> anyway.
Thank you - and that might the better solution moving forward, is we cut a week 
off both halves if we release a patch two weeks after a release or a week off 
the testing time if we eat into the next release by a week.
Kind Regards
Steve
  ---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

RE: patch release tomorrow

[Daniel Stenberg]

On Sun, 7 Aug 2016, Steve Holme wrote:

I also appreciate this is a little subjective but I would have thought 
adding support for NTLM with mbedTLS is also a new functionality - 
previously NTLM wasn't supported with mbedTLS so I wouldn't class that as a 
bug fix.


That's of course a matter of defintion and while it perhaps isn't strictly a 
bug that was fixed, since it was very much deliberate. But I consider it a bug 
when a particualr backend doesn't support the full feature set so when we fix 
that it is a bug fix. I don't view it as a real "change" either since 
supporting NTLM is something we've done for decades. Tricky.


It seems to me that, those 4 weeks of testing and bug fixing aren't going to 
be used as well as they could be. With regards to testing there hasn't been 
much added since the last weeks release so not a huge amount of stuff to 
test.


I beg to differ. We're constantly behind on bug fixing (and associated tests) 
so even without anything added we still have lots of things to fix and test. 
Just see the KNOWN_BUGS and the open issues. Several of those have been around 
for a long time and I struggle to keep up.


I would agree that we're probably not that many people doing this kind of 
debug and test work, so the bugfixing period may actually be taken by some (or 
many) as a hint to go procrastinate until the feature window opens again but 
I'm not sure that's a very good argument for us to change habits.


So, do you or anyone else want another week for adding features until we 
close that for the next release?


Please - and it the chance for other features to drop in as well.


Absolutely! The feature window is hereby extended one week - it'll now close 
on August 17. Let's try to keep the pending release date at September 7th 
anyway.


--

 / daniel.haxx.se
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

RE: patch release tomorrow

[Steve Holme]

> On Sat, 6 Aug 2016, Daniel Stenberg wrote:

> > I've already push Bill's mbedTLS NTLM addition and I'm hoping to get 
> > Sergei's LDAP change pushed this weekend (although I might to step up and 
> > finish the documentation side off!). Is this enough for a major bump as I 
> > probably need to quote version numbers in the docs for LDAP?
> 
> Is it? I'll admit I haven't really followed the details of the LDAP changes 
> but I've not seen anything there that isn't just bugfixes. Am I wrong?
I see Sergei has already responded but I would have said that was a new feature.
I also appreciate this is a little subjective but I would have thought adding 
support for NTLM with mbedTLS is also a new functionality - previously NTLM 
wasn't supported with mbedTLS so I wouldn't class that as a bug fix.
> > I've also been wondering about this process... I know we have our 8 week 
> > release cycle but when a patch release eats into this, I would rather reset 
> > the 8 week cycle so it starts in full from that patch release date
> 
> There are several ways we could do it. We don't do patch release out of the 
> ordinary schedule that often so we haven't made any formal decisions on how 
> to 
> handle it. This time, I figured we could do it this way since we have so many 
> bugs to work on anyway so it would be a general benefit to have a "round" 
> where we have less time for features and more time for bugs. That. and the 
> fact that I wasn't aware of any major changes knocking on the door longing to 
> get in.
Don't get me wrong, I don't have any problems with the patch releases out of 
the 8 week cycle.
> > I appreciate it means updating the calendar and it means you can't 
> > guarantee 
> > a release on say 22 February 2017, but I would be interested to know what 
> > others think as it would allow more time to get features in. From a totally 
> > selfish point of view, as I am struggling to dedicate time to curl at the 
> > moment, it would certainly help me ;-)
> 
> Right, but if you wouldn't manage to reach a mergable state for the change 
> within this week final, there is only another four weeks until the feature 
> window opens again and there's another opportunity. I don't think it should 
> be 
> much of a burden for people as long as we open up for features again soon 
> enough.
It seems to me that, those 4 weeks of testing and bug fixing aren't going to be 
used as well as they could be. With regards to testing there hasn't been much 
added since the last weeks release so not a huge amount of stuff to test.
> An alternative would of course be to make patch releases in a separate branch 
> so that we can do feature merges in the branch heading for the next minor 
> release but I would prefer to avoid such a setup as it would make it more 
> complicated to test and for us to keep track of.
Yeah - I would agree with you there I never like the setup, maintenance and 
management of multiple branch ;-)
> So, do you or anyone else want another week for adding features until we 
> close 
> that for the next release?

Please - and it the chance for other features to drop in as well.
Kind Regards
Steve
  ---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Re: patch release tomorrow

[Sergei Nikulov]

2016-08-06 22:25 GMT+03:00 Daniel Stenberg :
> On Sat, 6 Aug 2016, Steve Holme wrote:
>
>> I've already push Bill's mbedTLS NTLM addition and I'm hoping to get
>> Sergei's LDAP change pushed this weekend (although I might to step up and
>> finish the documentation side off!). Is this enough for a major bump as I
>> probably need to quote version numbers in the docs for LDAP?
>
>
> Is it? I'll admit I haven't really followed the details of the LDAP changes
> but I've not seen anything there that isn't just bugfixes. Am I wrong?
>

It is new feature.
But it's small changes in code - I've reused existing auth options from HTTP.

>
> --
>
>  / daniel.haxx.se
> ---
> List admin: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette:  https://curl.haxx.se/mail/etiquette.html



-- 
Best Regards,
Sergei Nikulov
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

RE: patch release tomorrow

[Daniel Stenberg]

On Sat, 6 Aug 2016, Steve Holme wrote:

I've already push Bill's mbedTLS NTLM addition and I'm hoping to get 
Sergei's LDAP change pushed this weekend (although I might to step up and 
finish the documentation side off!). Is this enough for a major bump as I 
probably need to quote version numbers in the docs for LDAP?


Is it? I'll admit I haven't really followed the details of the LDAP changes 
but I've not seen anything there that isn't just bugfixes. Am I wrong?


I've also been wondering about this process... I know we have our 8 week 
release cycle but when a patch release eats into this, I would rather reset 
the 8 week cycle so it starts in full from that patch release date


There are several ways we could do it. We don't do patch release out of the 
ordinary schedule that often so we haven't made any formal decisions on how to 
handle it. This time, I figured we could do it this way since we have so many 
bugs to work on anyway so it would be a general benefit to have a "round" 
where we have less time for features and more time for bugs. That. and the 
fact that I wasn't aware of any major changes knocking on the door longing to 
get in.


I appreciate it means updating the calendar and it means you can't guarantee 
a release on say 22 February 2017, but I would be interested to know what 
others think as it would allow more time to get features in. From a totally 
selfish point of view, as I am struggling to dedicate time to curl at the 
moment, it would certainly help me ;-)


Right, but if you wouldn't manage to reach a mergable state for the change 
within this week final, there is only another four weeks until the feature 
window opens again and there's another opportunity. I don't think it should be 
much of a burden for people as long as we open up for features again soon 
enough.


An alternative would of course be to make patch releases in a separate branch 
so that we can do feature merges in the branch heading for the next minor 
release but I would prefer to avoid such a setup as it would make it more 
complicated to test and for us to keep track of.


So, do you or anyone else want another week for adding features until we close 
that for the next release?


--

 / daniel.haxx.se
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

RE: patch release tomorrow

[Steve Holme]

On Tue, 2 Aug 2016, Daniel Stenberg wrote:

> It is quite possible that the next release following 7.50.1 also will become 
> a 
> patch release since we don't have any particular changes queued up (that would
I've already push Bill's mbedTLS NTLM addition and I'm hoping to get Sergei's 
LDAP change pushed this weekend (although I might to step up and finish the 
documentation side off!).
Is this enough for a major bump as I probably need to quote version numbers in 
the docs for LDAP?
> require a minor number bump) and there's just one week left until the 
> official 
> cut-off date for the change window.

I've also been wondering about this process...
I know we have our 8 week release cycle but when a patch release eats into 
this, I would rather reset the 8 week cycle so it starts in full from that 
patch release date - I appreciate it means updating the calendar and it means 
you can't guarantee a release on say 22 February 2017, but I would be 
interested to know what others think as it would allow more time to get 
features in.
>From a totally selfish point of view, as I am struggling to dedicate time to 
>curl at the moment, it would certainly help me ;-)
Kind Regards
Steve
  ---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Re: patch release tomorrow

[Daniel Stenberg]

On Tue, 2 Aug 2016, Richard Gray wrote:

Possibly most notable: we're reverting the change that modified the CURL, 
CURLM and CURLSH types and they go back to be 'void *' unless you define 
CURL_STRICTER before including our headers.


I wonder if there's an itch that wants to be scratched in terms of a 
curl_lite.h or #define CURL_MINIMAL or something...


Maybe. But I prefer not to act on something like that until we get someone who 
actually have that itch come here and advocate for something like that so that 
we A) are sure there truly are people who want and would use something like 
that and B) we would do it in a way that would accurately scratch the itches 
of such people...


--

 / daniel.haxx.se
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Re: patch release tomorrow

[Daniel Stenberg]

On Tue, 2 Aug 2016, Ray Satiro via curl-library wrote:

I don't think that is the lesson here. I recall it has happened more than 
once that a file needed by a release is missing. The lesson I think would be 
to build from the planned release tarball prior to the actual release to 
make sure it builds and all the tests complete successfully.


I consider that to be more of the last resort. It would be much better if we 
built a system that would detect such problems as early as possible instead of 
having me have to hunt them down at releast time... If the test suite detects 
them, it also shows up already for pull-requests etc which is lovely!


--

 / daniel.haxx.se
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Re: patch release tomorrow

[Richard Gray]

dev_user wrote:

On 08/02/2016 05:18 AM, Daniel Stenberg wrote:

Hi all!

I'll put together a 7.50.1 patch release tomorrow.

...



Possibly most notable: we're reverting the change that modified the
CURL, CURLM and CURLSH types and they go back to be 'void *' unless

 > you define CURL_STRICTER before including our headers.


I wonder if there's an itch that wants to be scratched in terms of a 
curl_lite.h or #define CURL_MINIMAL or something...



In an unrelated bug I have been living in my curl tee-shirt for more
than a few days in a few offices and thus far received comments like:

   1 - oh, I have heard of that. Its a new website protocol right?
   2 - you don't look like the type that works out a lot
   3 - why is that last bit green in colour?
   4 - I tried that in front of a url in my browser and it doesn't
 do anything.  [ I loved that one ]
   5 - is that related to surfing or swimming ?


5 - or involves brooms ?   ;P

Rich
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Re: patch release tomorrow

[Ray Satiro via curl-library]

On 8/2/2016 9:34 AM, Daniel Stenberg wrote:



7.50.0 :TESTFAIL: These test cases failed: 1139 1140

So hopefully 7.50.1 reports a 100% clear on the testsuite.


We run most of our autobuild tests directly from git, so for example 
these two tests 1139 and 1140 will succeed off git but fail in a 
relase where we've forgotten to include some files in the tarball - 
like we did in 7.50.0.


The lesson here is that we should perhaps have both 1139 and 1140 
actually work only on files that can be found in the makefiles (that 
would be included in the dist) so that we can detect these problems 
earlier and easier. I haven't really figured out the best approach. 


I don't think that is the lesson here. I recall it has happened more 
than once that a file needed by a release is missing. The lesson I think 
would be to build from the planned release tarball prior to the actual 
release to make sure it builds and all the tests complete successfully.
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Re: patch release tomorrow

[Daniel Stenberg]

On Tue, 2 Aug 2016, dev_user wrote:

Excellent. I will watch for that. As I noted on my email 27th July 2016 
there seems to be a few tests that fail in various versions released over 
the past little while :



7.50.0 :TESTFAIL: These test cases failed: 1139 1140

So hopefully 7.50.1 reports a 100% clear on the testsuite.


We run most of our autobuild tests directly from git, so for example these two 
tests 1139 and 1140 will succeed off git but fail in a relase where we've 
forgotten to include some files in the tarball - like we did in 7.50.0.


The lesson here is that we should perhaps have both 1139 and 1140 actually 
work only on files that can be found in the makefiles (that would be included 
in the dist) so that we can detect these problems earlier and easier. I 
haven't really figured out the best approach.


In general though, all test failures are not alike. Failing these two 
particular tests in a release for example is not a big deal (for me) as long 
as they work in git.


Possibly most notable: we're reverting the change that modified the CURL, 
CURLM and CURLSH types and they go back to be 'void *' unless you define 
CURL_STRICTER before including our headers.


That is interesting. I wonder if there is a test for that.


We don't have a test for that and really, the change only hit people and 
applications that second-guessed what the types are and do their own forward 
declarations of them instead of including our headers.


While I'm not sure we actually violated the API with this, it seemed at least 
10 or so applications had code like this and I think that was too hard of a 
blow for me to insist that we were right. Now at least "good" applications can 
opt in to stricter type checks with this define.


However I have to agree that there is no reason to promise or even suggest 
that curl "symbols are free for others to forward declare like that."  I 
certainly don't have a compile or link problem and last time I checked I 
have 90,000+ lines of code to deal with inside my applications here. Not a 
single error.


I agree. I suspect a vast majority of all libcurl users had no problems at all 
with that change. Still...


Wish I could do more. I am sure you know that libcurl has become an 
essential component.


I'm aware => https://daniel.haxx.se/blog/2016/05/31/on-billions-and-users/

But libcurl sneaking into just about every device on the planet haven't made 
our "dev team" to grow in the same speed...


In an unrelated bug I have been living in my curl tee-shirt for more than a 
few days in a few offices and thus far received comments like:



 4 - I tried that in front of a url in my browser and it doesn't
   do anything.  [ I loved that one ]


That's lovely. We clearly hang out in different circles because when I've worn 
my t-shirt I've had several people ask me if we have registered that URL 
scheme (and yeah, I've toyed with the idea of putting an internet-draft 
together for it...)! Several people on twitter also asked me if just two 
slashes really are enough. =)


Unfortunately I've not yet received any curl stickers!

--

 / daniel.haxx.se
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Re: patch release tomorrow

[dev_user]

On 08/02/2016 05:18 AM, Daniel Stenberg wrote:

Hi all!

I'll put together a 7.50.1 patch release tomorrow.


Excellent. I will watch for that. As I noted on my email 27th July 2016 
there seems to be a few tests that fail in various versions released

over the past little while :


7.47.0 :TESTDONE: 771 tests out of 771 reported OK: 100%
7.47.1 :TESTDONE: 771 tests out of 771 reported OK: 100%
7.49.0 :TESTDONE: 780 tests out of 782 reported OK: 99%
7.49.0 :TESTFAIL: These test cases failed: 1139 1140
7.49.1 :TESTDONE: 782 tests out of 782 reported OK: 100%
7.50.0 :TESTDONE: 784 tests out of 786 reported OK: 99%
7.50.0 :TESTFAIL: These test cases failed: 1139 1140

So hopefully 7.50.1 reports a 100% clear on the testsuite.


Possibly most notable: we're reverting the change that modified the
CURL, CURLM and CURLSH types and they go back to be 'void *' unless

> you define CURL_STRICTER before including our headers.

That is interesting. I wonder if there is a test for that. Probably
possible to have a ten line test.  However I have to agree that there
is no reason to promise or even suggest that curl "symbols are free
for others to forward declare like that."  I certainly don't have a
compile or link problem and last time I checked I have 90,000+ lines
of code to deal with inside my applications here. Not a single error.


As always: we can really use your help!


Wish I could do more. I am sure you know that libcurl has become an
essential component. There may still be plenty of folks hand rolling
their code to fetch or submit data across networks using the TCP/IP
manuals, OpenSSL and coffee but libcurl gets the job done far better.

In an unrelated bug I have been living in my curl tee-shirt for more
than a few days in a few offices and thus far received comments like:

  1 - oh, I have heard of that. Its a new website protocol right?
  2 - you don't look like the type that works out a lot
  3 - why is that last bit green in colour?
  4 - I tried that in front of a url in my browser and it doesn't
do anything.  [ I loved that one ]
  5 - is that related to surfing or swimming ?

I was surprised that not a single person could "get it". So, that's a
human bug possibly fixed with me telling them "look up libcurl because
it's everywhere."

Dennis

---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

patch release tomorrow

[Daniel Stenberg]

Hi all!

I'll put together a 7.50.1 patch release tomorrow. It'll include fixes for 
three minor security problems and the set of bugfixes we've landed so far 
since 7.50.0.


Possibly most notable: we're reverting the change that modified the CURL, 
CURLM and CURLSH types and they go back to be 'void *' unless you define 
CURL_STRICTER before including our headers. The full history of that change 
can be found here: https://curl.haxx.se/bug/?i=926


I've deliberately been saving the TCP_NODELAY change and I'll save merging the 
SFTP/SCP patch until after tomorrow's 7.50.1.


It is quite possible that the next release following 7.50.1 also will become a 
patch release since we don't have any particular changes queued up (that would 
require a minor number bump) and there's just one week left until the official 
cut-off date for the change window.


As always: we can really use your help! The number of issues and pull-requests 
on github[1] grow faster than we manage to fix/merge them...


[1] = https://github.com/curl/curl

--

 / daniel.haxx.se
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html