Re: Bug#364652: ITP: squid3 -- Internet Object Cache (WWW proxy cache) version 3
#include <hallo.h>
* Luigi Gangitano [Wed, Apr 26 2006, 12:21:52PM]:
> >>Squid 3 is not release ready. And with current plans should not
> >>release
> >>with etch.
> >
> >Upload to experimental, not as new source.
>
> Why not? Since I'd like to make squid3 easily available to all those
> that want to try the new features, without braking the existing squid
> package, unstable is the most obvious solution (autobuilt on all
> archs, widely deployed on desktop/testing machine, no configuration
> needed), don't you think?
How would that interact with running squid installations? Please tell us
what the actuall constraints are instead of repeating "needs to stay
here, needs to stay there". I assume you want to:
- make a package name more clear to show what the purpose of that
package is. Eg. "squid-experimental"
- clearly state that this is an experimental package, that it does not
share configuration or cache data with default squid installation
- upload the package either to unstable or to experimental, depending
on your opinion of how much damage the package may create. Actually,
I would upload it to experimental only.
- keep config directories and cache data separate
- when squid-3.x is released, upgrade squid package with the new
version PLUS the changes from squid-experimental PLUS transition code
if needed. THEN upload the package as "squid" to experimental, THEN
ask people to install it from experimental to test the upgrade path.
And then move it to unstable for more wide testing.
> Unstable is where such testing can happen, think zsh-beta or
> different versions of postgres.
Ehm... zsh-beta is a different class of application, not something that
can fsck up your system RSN by offering remote accessible vulnerability.
Eduard.
Reply to: