Varnish project autumn cleaning

[Poul-Henning Kamp]

--------
In message <CAJV_h0bg_tqEVyaCX3Gi0NgRt7cFSRKu1c4ccCP_K4FiObn4ig at mail.gmail.com>
, Federico Schwindt writes:

>It might be worth exploring
>https://help.github.com/articles/user-organization-and-project-pages/ for
>the website and/or wiki.

Or we could look at Wikia, which has been a Varnish-user from the
very get go...

>One question that comes to my mind is what is going to happen with
>repo.varnish-cache.org after we move out of VS.
>Are we going to continue providing packages?

That's a very murky question for me.

My preference would be for varnish itself to be OS packages, reachable
by regular OS packaging tools.

Some high-profile VMODs may be able to scale that barrier too, but
the majority wont.

So the question is rally:  What do do with the "community VMODs" ?

The keyword here is automation:  We do not want to manually curate
all the worlds VMODs.

At the lowest level, I'd like to define a "protocol", something
like "include a VMOD.README file in your project" (inspired by
FreeBSD's portcollections ".desc" file) and have a google search
which find all of those files on github and list the projects on
the webpage.

Ideally we'd also pull them and try to build them, so we only list
those which can compile, and can tell which varnish versions they
compile against.

If they have .vtc files, we test them too.

If they fail, we email the maintainer, and black-ball them until
their next github commit.

But that is both tedious and nasty business.

You *really* don't want to pull random github projects and run their
instructions unsupervised without some very strong boundary
protections.

On the other hand, with jails/containers/VMs, that is not as
outrageous as it used to be, so it is a feasible project with a
high payoff on the far side.

In particular if we follow the compilation up with rolling a package.

That 'vmod-package-engine' should obviously be as cross-platform
as possible, even though the actual containment strategy would be
different on different OS's.

But without automation, it's a dead end:  We don't have the manpower
to manually curate them.

Anybody want to attempt something like this ?

(Here's the blueprint: http://www.dmi.dk/uploads/pics/stormp.gif)


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.