Thanks for your perspective Willy, The reason this comes up now, is that currently we maintain vtest (badly) in both the dedicated vtest repository and in the V-C respository, and that is not ideal.
Slightly complicating things even more is that VTest is built on top of library code which lives in V-C repo, but is (also) copied to the VT repo. I'm trying to find are more sensible way to do things, preferably one which is easier for everybody. I dont think anybody is eager to turn VT into a "full project" with releases, backwards compat and all that, and I dont thing anybody would be happier even if we did. So the main question for us in V-C is of we continue as now, or use the VT repo as a sub-respository, so we only maintain VT one place. There is a secondary (and IMO minor) issues, such as if we should recreate the VT repo to retain the full history (The current VT repo was created by checking in a snapshot). The actual code would be the same, but obviously commit ID's would change. Any thoughts on this ? -- 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
