VC release management in the future (Was: Re: Varnish project autumn cleaning)

Poul-Henning Kamp phk at phk.freebsd.dk
Wed Oct 28 12:59:06 CET 2015


--------
In message <20151028104750.GC1274 at immer.varnish-software.com>, Lasse Karstensen
 writes:

>I understand there will be no stable version, just a continous stream of
>make dist from git master every 6 months.

No, I don't think we should drop stable versions, but we can't make
all the head-releases into stable versions, that wouldn't scale.

The process I see is that we do a head-release twice a year, and
once we get to know them, because people on the bleeding edge have
tried them out, we pick the ones we will support as stable
releases for a longer time.

>Am I right to assume that distros would then just pick the one latest
>available 3-6 months before they cut a release, and then live with it
>for 3-5 years during the linux distro lifespan?

I have no idea, that would be entirely up to them.  If we do as I propose
above, they would likely pick the most recent annointed stable release.

>Also, since we're not doing a stable release any longer, who is
>backporting the bugfixes all of these n packagers need to keep the
>Varnishes in their distro safe and reliable?

That's a very important question, and the answer is as disappointing
as it can be:  Whoever has the time and inclination.

A project of our size has to economize its resources, and one way to
do that is to ruthlessly tell people to upgrade.

>[cut]
>> Some high-profile VMODs may be able to scale that barrier too, but
>> the majority wont.
>
>This is not correct.
>
>The majority of vmods in use are on the way into EPEL and Debian these
>days. I understand there is some work being done on the FreeBSD ports
>side as well.

That would be a lovely state of affairs, I hope you're right.


-- 
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.



More information about the varnish-dev mailing list