Divorcing varnishtest from varnish-cache

[Willy Tarreau]

Hi Poul-Henning!

On Sat, Sep 22, 2018 at 05:34:17PM +0000, Poul-Henning Kamp wrote:
> We discussed this at our developer summit in Hamburg yesterday
> and I had made some experiments on the train down there.
> 
> The suggested plan right now is:
> 
> 1. Try to gain control of the empty 'vtest' account on github
>    I've sent them a message.  (Do we know any insiders ?)
>    Alternative name suggestions if this fails are most welcome.

Unfortunately they don't have much balls overthere. We've had quite
some difficulties recovering the haproxy account. All they could do
was to point us to other projects the same contributor contributed
to hoping that we could contact him opening issues overthere :-/

In the end we were lucky because the guy is very friendly to haproxy
and was just never reading his emails, so once he found them he moved
around and let us install our stuff there. So I woudln't count on any
help from github. I think they are very strict regarding any form of
information leak, which can be understandable given the numerous
projects they host.

I'd suggest to try to contact the vtest account owner directly. If
that fails, maybe leaving it under the varnish account would still
make sense since that's where it comes from and it's not a secret.

> 2. Create a vtest repository which contains:
> 
>    ./README
>    ./Makefile
>    ./lib/
> 	(slimmed down) files from lib/libvarnish
>    ./src/
> 	bin/varnishtest/*.[ch]
>    ./tests/
> 	a?????.vtc tests, purged from varnishd usage
> 
>    My in-train test got it down to 29kLOC.

Quite good!

> 3. Give developer access to interested & trustworthy parties
> 
>    We should probably define an informal review/design process, so
>    that nobody drags the carpet under somebody else by accident.

Probably.

> 4. No binary packages/releases will be built at this time
> 
>    HAproxy and Varnish-Cache can/will import by whatever
>    means from the new common 'vtest' project, and build
>    vtest the way which works best for their project.
>    (V-C obviously have some backwards compat issues)

I think that emitting a 1.0 version "soon" could boost adoption and
send a signal that it's good enough for what all of us currently need.
It seems to me that the utility is already usable on both projects so
it might be a good way to tell the community "look, now it's born,
it's reliable, if it finds bugs they're more likely in the project
that uses it than in the utility itself". With a bit of luck, other
projects could be attracted.

Thanks for the update!
Willy