[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: