Subject: Re: Timeline for a new c-ares release

Re: Timeline for a new c-ares release

From: David Drysdale <drysdale_at_google.com>
Date: Mon, 18 Jan 2016 11:34:48 +0000

On Wed, Jan 13, 2016 at 2:27 PM, David Drysdale <drysdale_at_google.com> wrote:
> On Wed, Jan 13, 2016 at 1:28 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>> On Sat, 9 Jan 2016, Gregor Jasny wrote:
>>
>>> Would it make sense to create a new release?
>>
>>
>> Yes it would!
>>
>> There have been a bunch of patches flying around that I personally haven't paid much attention to. Is there anything important we should make sure to get done before we ship ?
>
> It would be nice to sort out the status of the test suite before
> shipping a new version, as I've got:
> - various API changes to allow for easier testability
> - a collection of (mostly small) bug fixes that the tests have uncovered.
>
> None of the changes are in the master repo, as I wanted to get an OK
> from someone other than me before committing (and a couple of the
> changes could probably do with a bit of discussion).

OK, I've created a pull request with a chain of commits arising from the
test suite efforts. I've shuffled things around so that the commits come
in the rough order:
 - fixes to the library code
 - extensions to the interface to the library to allow more testability
 - changes to the build system (mostly because the test scripts share
   the m4/ directory)
 - doc changes
 - test code (which I'm treating as test/* and *.yml)

[Update: actually, the GitHub UI shows the commits in date order
rather than in commit-order from the branch, so it might be easier to look
at: https://github.com/daviddrysdale/c-ares/commits/test-for-merge]

I think someone else should look over each of those sets of commits,
with the exception of the ~45 test-specific commits (as that shouldn't
affect a normal library user). I think Daniel has OKed the first two fix
commits, but the rest need a look.

All of the API extensions/changes are obviously worth a particularly
close look, but there's also a couple of the fixes that might warrant
more thought:
  - EDNS0 fallback fix (fc968acb)
  - ares_init_options: is this the right behaviour on failure? (933e5662)
  - ares_striendstr: did this ever work? or have I completely
    misunderstood it? (f728e437)

Regards,
David

>> --
>>
>> / daniel.haxx.se
Received on 2016-01-18