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.
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.
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.
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)
5. See where that takes us.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[email protected] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-dev mailing list
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
